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1.0  INTRODUCTION 


One  of  the  potentially  most  valuable  research  areas  within 

Artificial  Intelligence  (AI),  from  the  perspective  of  military 
applications,  involves  the  development  of  automatic  planning  systems. 
AI  planners  not  only  have  the  potential  of  autonomously  solving 

various  low-level  planning  problems  such  as  in  robotics  applications, 
but  can  form  the  basis  of  expert  consultation  systems  for  higher  level 
military  planning  problems,  (e.g.,  planning  division  level  maneuvers). 

Most  of  the  work  in  AI  action  planning  has  been  done  in  the 

context  of  robot  problem  solving,  where  the  planners  developed  in  this 
context  can  be  extended,  at  least  in  principal,  to  other  domains. 
Recent  research  in  this  area  has  focused  on  the  development  of 
techniques  to  extend  action  planners  to  real  world  complex  problem 
domains.  In  particular,  these  efforts  have  focused  on  adapting 
planners  to  uncertain  and  unpredictable  environments  where  multiple 
components  of  the  plan  may  be  executed  in  parallel  by  distributed 
execution  modules.  Although  this  work  is  relevent  to  the  development 
of  practical  AI  planners,  from  the  perspective  of  eventual  military 

value,  it  is  inherently  limited,  in  particular,  these  planners  lack  a 
satisfactory  capability  to  explicitly  incorporate  an  adversary’s  goals 
and  actions  into  the  planning  process.  Consequently,  they  cannot 
effectively  plan  against  an  adversary  that  is  simultaneously  planning 
against  them. 

To  illustrate  the  importance  of  incorporating  an  adversary.' s 
goals,  consider  the  work  in  planning  under  uncertainty.  One  accepted 
technique  is  the  use  of  information  goals,  where  if  information 
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necessary  to  execute  a  plan  is  not  available  to  the  planner,  then  a 
goal  of  collecting  the  required  information  is  added  to  the  plan, 
(e.g.,  FIND_LOC(x) ,  if  location  of  x  is  not  known).  When  an  adversary 
is  present,  however ,  that  adversary  is  likely  to  have  a  counterplan  to 
prevent  the  collection  of  the  required  information,  and  may  use  any  of 
a  variety  of  tactics  (e.g.,  have  a  goal  of  DECE3VE_L0C (x) )  to  achieve 
this  end.  Unless  the  adversary's  counter  goals  and  actions  are 
explicitly  taken  into  account,  the  information  goal  is  not  likely  to 
be  achieved. 

In  this  report  we  discuss  the  problem  of  extending  action 
planning  techniques  to  problems  involving  planning  against  an 
intelligent  adversary.  In  particular,  this  report  summarizes  the  work 
performed  in  the  first  year  of  a  research  program  to  develop  automated 
adversarial  planning  techniques.  Section  2.0  provides  some  background 
on  AI  planning  and  game  playing  research.  Section  3.0  describes  in 
some  detail,  the  capabilities  and  planning  procedures  of  CP/1.0 
(Contingency  Planner/Version  1.0) ,  our  first  version  of  a  general 
adversarial  planning  system.  In  addition.  Section  3.0  also  discusses 
each  individual  action  planning  technique  discussed  in  Section  2.0, 
and  discusses  how  they  might  be  incorporated  into  the  CP/x  framework 
and  therefore  extended  to  adversarial  planning  problems.  Section  4.0 
briefly  addresses  our  plans  for  the  next  two  years  of  this  program. 
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2.0  BACKGROUND 


in  this  section,  research  relevant  to  the  development  of 
adversarial  planning  techinques  is  reviewed. 

2. 1  Single  Agent  Action  Planning 

Most  of  the  artificial  intelligence  (AI)  work  in  planning  has 
been  done  in  the  context  of  research  where  a  single-agent  (e.g.,  a 
robot)  must  plan  a  sequence  off  action.  Since  the  goal  of  this  work  is 

to  extend  planning  techniques  to  adversarial  planning  problems, 
relevant  action  planning  techniques  are  introduced  below. 

2.1.1  Goal-Driven  Action  Planning 

Within  AI  research,  a  common  planning  task  involves  a  robot 
(real  or  hypothetical)  that  exists  in  some  type  of  blocks  world.  The 
robot  is  given  tasks  which  require  it  to  move  the  blocks  into  some 
particular  configuration.  Before  starting,  the  robot  is  required  to 
'figure  out'  what  actions  need  to  be  taken,  i.e.,  to  make  a  plan. 

Some  early  planners  (e.g.,  Fikes,  et .  al . ,  1972)  would  solve 
problems  such  as  this  through  a  'backward  chaining'  procedure.  In 
this  approach,  the  planner  is  given  a  set  of  goals  that  are  sufficient 
to  describe  the  goal  state,  a  description  of  the  initial  state  of  the 
world  and  a  set  of  permissable  operators  or  actions  that  can  modify 
the  world  state.  The  planner  then  looks  at  each  goal,  matches  it 
against  the  present  world  state  and  if  it  is  not  already  true,  looks 
for  an  operator  that  can  achieve  it.  If  the  operator  cannot  be 
applied,  because  a  precondition  of  its  use  is  not  satisfied,  then  the 

£  t 

unsatisfied  precondition  becomes  a  new  goal  to  be  achieved.  This 
process  is  recursively  repeated  until  all  goals  are  satisified. 
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To  illustrate  this  approach,  assume  that  we  have  a  robot  that 
exists  in  a  world  consisting  of  three  square  blocks  and  a  table. 
Assume  further  that  the  blocks  are  initially  set  up  as  in  Figure  2-1. 
The  robot  is  capable  of  only  one  action,  PtJTON(x,y),  which  means  pick 
up  block  x  and  put  it  on  top  of  object  y.  y  can  either  be  another 
block  or  the  table.  PUTON  can  only  move  one  block  at  a  time.  Assume 

further  that  our  robot  has  been  given  the  task  of  moving  the  blocks  so 

that  block  A  is  on  top  of  B  which  is  on  top  of  C  (see  Figure  2-2). 

This  goal  state  can  be  described  by  the  conjunction  of  goals 

ON ( B ,C )  and  ON(A,B).  Assume  our  robot  has  been  given  these  goals,  and 

it  begins  by  trying  to  attain  the  first  one,  ON(B,C).  Now,  in  order 

to  obtain  this  goal,  the  action  PUTON(B,C)  must  be  executed.  However, 

this  action  cannot  be  executed  until  the  precondition  that  'C  is 
clear'  is  true.  Consequently,  CLEAR (C)  becomes  a  new  goal  to  be 
achieved.  PUTON (C, Table)  can  directly  achieve  this  and  is 
consequently  the  first  action  in  the  plan.  Once  C  is  clear, 

PUTON (B,C)  is  now  executable  and  therefore  becomes  the  second  action. 

At  this  point  ON(B,C)  has  been  achieved,  and  ON(A,B)  which  is 
executable.  Consequently,  this  becomes  the  third  action  in  the  plan, 
at  which  point  the  plan  is  complete. 

One  way  to  record  this  planning  process  is  by  the  use  of  a 
hierarchical  goal  tree  where  each  goal,  subgoal  and  action,  that  is 
part  of  the  plan,  corresponds  to  a  node  in  the  tree.  For  example,  a 
goal  tree  that  corresponds  to  the  plan  generated  in  the  above  example 
is  found  in  Figure  2-3.  There  are  two  features  of  this  goal  tree  that 
should  be  noticed.  First  the  sequence  of  actions  in  the  final  plan 
are  contained  in  the  terminal  nodes.  Simply  read  them  from  left  to 
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TABLE 


FIGURE  2-1 

INITIAL  CONFIGURATION  FOR  BLOCKS 
WORLD  PROBLEM 


ON(B,C)  A  ON(A,B) 

/  \ 

ON(B,C)  ON(A,B) 

/  \  \ 

clear(b)  puton(b,c)  puton(a,b) 

/ 

PUTON(C, TABLE) 


FIGURE  2-3 


GOAL  TREE  FOR  BLOCKS  WORLD  PROBLEM 


right.  Second,  by  examining  the  ancestors  for  each  action,  we  can 
determine  why  each  action  needs  to  be  taken.  For  instance,  the  action 
PUTON (C, Table)  is  taken  to  CLEAR(C),  which  is  necessary  before  ON(B,C) 
can  be  achieved,  which  is  one  of  the  original  goals  to  be  achieved.  A 
robot  problem  solving  plan  that  is  represented  as  a  goal  tree, 
therefore,  not  only  consists  or  the  actions  that  need  to  be  executed, 
but  also  of  an  explanation  of  why  each  action  is  needed.  It  is  also 
important  to  note  that  this  goal  tree  was  generated  through  a 
recursive  'depth-first1  expansion  of  the  tree.  For  instance,  before 
adding  ON(A,B)  to  the  goal  tree,  all  of  the  descendants  of  ON(B,C) 
were  added  first. 

2.1.2  Hierarchical  and  Parallel  Planning 

More  recent  planners  (e.g.,  Sacerdotti,  1976,  1977;  Vere ,  1981) 
have  introduced  two  important  innovations  to  this  simple  goal-seeking 
process;  hierarchical  plans  and  the  production  of  parallel  plans.  In 
hierarchical  planning,  goals  and  subgoals  are,  in  effect,  put  in  a 
priority  order.  The  more  important  goals  are  first  worked  out  to  a 
reasonable  level  of  detail  (i.e.,  working  out  the  major  steps  of  the 
plan),  and  less  important  goals,  the  details,  are  considered  later. 
One  common  technique  for  implementing  hierarchical  planning  is  to 
postpone  consideration  of  preconditions.  In  the  above  example,  for 
instance,  the  consideration  of  the  CLEAR (C)  precondition  would  be 
delayed  until  ON(A,B)  was  first  considered  and  added  to  the  goal  tree. 
In  another  context,  say  planning  a  trip  from  Washington  to  Chicago, 
there  is  J.ittle  value  in  determining  the  details  of  getting  to  an 
airport  until  the  major  step  of  determining  which  flight  to  take,  and 
therefore  which  airport,  has  been  completed. 
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In  parallel  planning,  instead  of  trying  to  achieve  a  set  of 
goals  in  some  order  and  then  trying  to  reorder  the  goals  if  this 
doesn't  work,  the  planner  assumes  all  goals  can  be  achieved 
simultaneously  unless  interactions  between  the  goals  are  found  that 
require  the  imposition  of  a  time  order  on  the  consequent  actions.  For 
instance,  in  the  above  example,  it  was  simply  fortuitous  that  the  goal 
ON (B,C)  was  explored  before  ON(A,B).  Assume,  ON(A,B)  were  the  first 
goal  achieved.  Then  when  ON(B,C)  is  explored,  the  first  subgoal 
generated,  CLEAR (C) ,  is  inconsistent  with  the  fact  that  ON(A,B)  has 
been  achieved,  requiring  that  the  planner  must  undo  ON(A,B) .  In 
parallel  planning,  ON(A,B)  and  ON(B,C)  would  be  assumed  to  be 
seperately  obtainable  goals  until  it  was  'discovered'  that  a 
consequence  of  achieving  ON(A,B)  is  that  it  violates  a  precondition  of 
the  action  PUTON(B,C),  namely  that  CLEAR ( B)  is  true.  This  would 
result  in  the  planner  requiring  that  ON(B,C)  be  attained  before 
ON ( A ,  B)  . 


As  can  be  seen,  an  important  advantage  of  parallel  planning  is 
that  it  avoids  premature  commitment  to  a  particular  ordering  of  goals 
and  actions,  thereby  avoiding  the  unnecessary  work  on  an  infeasible 
ordering  that  was  initially  selected  arbitrarily.  In  order  to 
represent  such  plans  with  parallel  branches,  the  goal  tree  format 
needs  to  be  expanded  so  that  goals/actions  can  be  represented  in 
parallel,  in  effect,  resulting  in  hierarchically  more  detailed 
PERT-like  networks.  In  AI,  such  PERT-like  networks  are  usually 
referred  to  as  a  Procedural  Nets. 

2.1.3  Skeleton  Plans 

Another  approach  to  planning  involves  the  use  of  stored 
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skeleton 


plans  that  outline  a  general  sequence  of  steps  for  solving  a 
variety  of  planning  problems  (Friedland,  1979).  planning  with 
skeleton  plans  usually  proceeds  in  two  stages.  First  a  skeleton  plan 
or  subplan  is  found  that  is  applicable  to  the  given  problem.  Second, 
the  abstract  steps  in  the  plan  are  filled  in  with  problem-solving 
operators  relevant  to  the  particular  problem  domain.  This 
instantiation  process  involves  large  amounts  of  domain-specif ic 
knowledge,  often  working  through  several  levels  of  generality  until  a 
problem-solving  operator  is  found  to  accomplish  each  step  in  a 
skeletal  plan.  If  a  suitable  instantiation  is  found  for  each 
abstracted  step,  the  plan  as  a  whole  will  be  successful. 


2.1.4  Opportunistic  Planning 

Another  approach  to  planning  is  that  of  opportunistic  planning 
(Hayesroth,  1980) .  This  approach  is  characterized  by  a  flexible 
control  strategy  that  allows  development  of  a  plan  in  a  combined 
bottom-up  and  top-down  fashion.  Problem  solving  actions  will  switch 
from  one  aspect  of  the  planning  problem  to  another  depending  on  where 
the  next  best  opportunity  exists  to  further  refine  a  partially 
completed  plan.  One  result  of  this  planning  approach  is  that  the 
planner  will  generate  various  islands  of  planning  action  (i.e.,  local 
subplans)  that  may  be  merged  into  a  single  integrated  plan  near  the 


end  of  the  planning  process. 


2.1.5  Meta  planninc 


Meta  planning 


is  a  general  term  that  refers  to  reasoning  about 


the  planning  process.  In  complex  problem  domains  where  alternative 
problem  solving  strategies  are  available,  it  is  useful  to  incorporate 


in  a  planner  a  mechanism  that  explicitly  reasons  about  the  best 


approach  to  solving  a  planning  problem.  Examples  of  this  kind  of 
reasoning  can  be  found  in  the  MOLGEN  system  (Stifick,  1981}  and  in  PAM 
(Wilensky,  1981) . 

2.1.6  Planning  in  Uncertain  Environments 

&  ^najor  restriction  of  most  planning  systems  is  "that  the 
planners  must  have  sufficient  information  about  the  target  world  to 
simulate  courses  of  action  to  the  level  of  detail  required  to  be  able 
to  predict  all  consequences  of  each  proposed  action.  Clearly,  this 

complete  world  knowledge  is  not  available  in  most  practical 
situations.  Indeed,  uncertainty  about  the  target  world  usually  comes 
in  many  forms,  such  as  a  lack  of  information  about  the  present  world 
state,  an  inability  to  fully  predict  the  affect  of  an  action  on  the 
world  state,  or  even  an  inability  to  anticipate  the  response  of  other 
agents  in  the  target  world.  Within  the  action  planning  area,  a  number 
of  techniques  are  being  explored  for  their  potential  to  handle  these 
types  of  uncertainty.  One  technique  for  planning  in  uncertain 
environments  involves  the  use  of  information  goals,  requiring  that 
certain  data  be  acquired  during  plan  execution.  For  example,  a  plan 
may  be  developed  that  includes  the  action  "move  object  A  to  location 
x",  even  if  the  location  of  A  is  unknown  to  the  planner.  This  can  be 
done  by  inserting  an  information  collection  goal  of  "Find  location  of 
object  A",  which  can  instantiate  a  "detect-by-TV"  operator  at  the  time 
of  execution. 

Another  set  of  techniques  for  planning  under  uncertainty 
involves  an  ability  to  dynamically  repair  plans.  In  most  context 
where  there  exists  a  significant  degree  of  uncertainty,  it  is 
impossible  to  plan  long  sequences  of  actions  in  advance,  because 


unexpected  conditions  usually  occur  very  early  during  the  execution  of 
the  plan.  In  this  type  of  context  the  planner  must  anticipate  a  need 
for  replanning.  An  economical  way  to  do  this  type  of  replanning  is  to 
isolate  the  previous  goals'  actions  affected  by  the  newly  discovered 
conditions,  and  then  ±o  replace  them  with  new  subplans  which  will  work 
in  the  new  state.  In  other  words,  attempt  to  save  as  much  of  the 
original  goal  tree  as  possible.  This  type  of  replanning  technique  can 
be  found  in  Hayes  (1975)  . 

2.1.7  Explicitly  Dealing  With  Time 

Most  planning  systems  treat  actions  as  though  they  occured 
instantaneously.  They  incorporate  no  model  of  what  happens  during  the 
execution  of  an  action,  and  consequently  are  incapable  of  describing 
world  states  during  action  execution.  Although  the  need  for  such 
time-dependent  models  is  commonly  accepted  (see  Sacerdotti,  1980), 
there  is  no  ongoing  work  in  this  area.  (See  Hendrix,  1973,  for  some 
early  work.) 

Another  way  in  which  time  can  be  dealt  with  involves  the 
scheduling  of  actions.  In  particular,  Tate  and  Daniels  (1977)  and 
Vere  (1981)  describe  planners  that  translates  simultaneous  actions  in 
parallel  plans  into  specific  action  start  and  end  times  in  a  PERT 
chart . 

2.1.8  Distributed  Execution  of  Plans 

When  parallel  branches  of  a  plan  are  generated,  it  may  be 
desirable  to  also  execute  them  in  parallel.  The  difficulty  that  often 
results  with  such  distributed  execution  is  the  occurance  of 
interactions  between  different  execution  modules.  Typically, 
interactions  are  detrimental,  and  generate  problems  involving  resource 


conflicts  and  the  undoing  of  each  others’  achievements. 

Techniques  being  developed  to  resolve  these  types  of  problems 
usually  involve  communication  protocols  that  keep  the  various 
execution  modules  informed  of  each  others  relevant  activities,  (e.g., 
Smith  1979)  and  general  procedures  that  enforce  independence  between 
modules  by  locally  resolving  interactions,  (e.g.,  such  as  when  two 
automobiles  arrive  simultaneously  at  an  intersection  and  the  vehicle 
on  the  right  side  has  the  right  of  way)  . 

2.1.9  Interactive  Planning 

Research  in  robot  and  other  automatic  problem  solving  domains 
have  resulted  in  a  number  of  planning  systems  that  function 
autonomously,  but  have  limited  capabilities.  One  way  to  expand  the 
capability  of  such  systems  is  to  develop  interactive  systems  where 
both  the  human  user  and  the  automatic  planner  cooperate  to  develop  a 
satisfactory  plan.  An  example  of  such  an  interactive  planner  is  fornd 
in  Wilkins  and  Robinson  (1981). 

2.1.10  Relevance  to  Adversarial  Planning 

It  is  clear  that  the  above-discussed  techniques  and  AI  planning 
issues  are  relevant  to  any  planning  domain,  including  adversarial 
planning.  Unfortunately,  from  the  perspective  of  planning  problems 
involving  an  adversary,  this  work  is  inherently  limited.  This  is 
because  neither  the  formalisms  for  representing  plans  nor  the  planning 
procedures  have  any  convenient  mechanisms  for  incorporating  the  goals 
and  actions  of  an  adversary. 

To  illustrate  the  importance  of  incorporating  an  adversary's 
goals,  consider  again  the  work  in  planning  under  uncertainty.  As 
noted  there,  information  collection  goals  are  sometimes  added  to  a 


plan  to  collect  necessary  data  at  the  time  of  plan  execution.  When  an 
adversary  is  present,  however,  he  is  likely  to  have  a  counterplan  of 
his  own  to  prevent  the  collection  of  the  required  information,  and  may 
use  any  of  a  variety  of  tactics  (e.g.,  deception)  to  achieve  this  end. 
Unless  the  adversary's  counter  goals  and  possible  actions  are 
explicitly  taken  into  account  during  planning,  the  information  goal  is 
not  likely  to  be  achieved. 

A  similar  problem  occurs  with  the  work  in  distributed  planning 
and  execution,  where  the  use  of  communication  protocols  and  procedures 
to  enforce  coordination  are  relied  upon.  When  an  adversary  is 
present,  that  adversary  is  likely  to  engage  in  actions  to  disrupt 
communication  and  coordination.  Consequently,  unless  these 
adversarial  countergoals  are  explicitly  considered  in  planning, 
successful  execution  of  the  plan  is  unlikely. 

2.2  AI  Game  Playing  Programs 

As  discussed  above,  most  of  the  research  in  AI  planning  has  been 
done  in  the  context  of  planning  the  actions  of  a  single  agent. 
Although  this  work  addresses  a  number  of  issues,  it  does  not  directly 
attack  the  problem  of  planning  against  an  adversary.  Another  area  of 
AI  planning  research,  that  is  specifically  oriented  toward  planning 
against  an  adversary,  involves  the  development  of  intelligent  game 
playing  programs.  The  relevance  of  this  work  to  the  more  general 
problem  of  planning  against  an  adversary  is  discussed  below. 

2.2.1  Goal-Driven  Game  Playing 

For  purposes  of  this  discussion,  two  types  of  game  playing 
programs  are  distinguished  as  those  which  utilize  a  ’planning  without 


goals'  approach  and  those  which  utilize  a  'planning  with  goals' 
approach.  A  typical  example  of  the  'planning  without  goals'  approach 
is  seen  in  the  Northwestern  University  chess  program  (Slate  & 


Atkinson , 

1978)  . 

This 

program 

selects  a 

move 

by 

examining  all 

possible 

sequences 

for 

six 

or 

seven 

moves . 

It 

then 

does  a  weighted 

linear 

evaluation 

of 

the 

features 

( relat ive 

number  of  points. 

mobility,  etc.)  of  each  of  the  terminal  positions.  The  program  then 
picks  the  move  that  maximizes  the  minimum  possible  evaluation  in  the 
terminal  positions.  At  no  point  during  the  planning  process  does  this 
program  focus  its  attention  on  achieving  specified  goals  or 
objectives.  Or  to  put  it  another  way,  the  program  contains  no 
conceptual  knowledge  about  what  it  should  be  trying  to  do,  rather  it 
uses  the  computational  power  and  speed  of  the  computer  to  review 
everything  it  can  do  and  then  through  a  simple  decision  rule,  chooses 
the  ' best '  . 

This  approach  has  been  very  successful  in  games  such  as 
checkers  and  chess  where  the  average  number  of  moves  in  a  position 
(around  8  for  checkers  and  25  for  chess)  is  small  enough  so  that  a 
more  or  less  thorough  examination  of  all  possible  move  sequences,  for 
at  least  several  moves  ahead,  is  feasible.  In  fact,  virtually  all  of 
the  chess  and  checkers  programs  noted  in  the  popular  literature,  such 
as  in  computer  chess  tournaments  or  programs  available  for  home 
computers,  use  some  variant  of  this  approach.  Unfortunately,  in  other 
games,  such  as  the  oriental  game  Go,  where  there  are  around  250  legal 
moves  per  position,  and  'real  life'  planning  under  adversity 
situations,  where  an  opponent  has  virtually  a  limitless  variety  of 
actions  available  to  him,  the  use  of  this  type  of  exhaustive  search 
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approach  is  not  feasible. 

An  alternative  approach  to  game  playing,  that  is  more  in  the 
mainstream  of  AI  research,  involves  the  use  of  goals  and  objectives  to 
control  the  move  look-ahead  process;  see  Berliner  (1977),  Pitrat 
(1976),  Wilkins  (1979),  Reitman  and  Wilcox  (1979),  Lehner  (1983).  The 
essence  of  this  approach  is  that  if  a  program  is  careful  in  selecting 
objectives  it  should  try  to  achieve,  then  it  should  be  sufficient  for 
planning  purposes  to  only  examine  actions  that  potentially  aid  in 

achieving  those  objectives. 

To  illustrate  this  goal-oriented  approach,  assume  that  we  have 
a  chess  position  where  one  player.  White,  believes  it  feasible  to  find 
a  mating  combination.  Consequently,  White  starts  with  the  goal  of 
CAPTURE_KING.  To  do  this.  White  isolates  a  square  he  needs  to  occupy 
with  his  queen  to  achieve  checkmate.  However,  this  square  is 
protected  by  a  black  knight.  Consequently,  REM0VE_KNIGHT  from  this 
square  becomes  a  subgoal.  This  type  of  subgoal  can  be  achieved  by 
actually  capturing  the  piece,  so  CAPTURE_KNIGHT  becomes  a  subgoal  of 
REMOVE_KNIGHT.  If  the  knight  can  be  directly  captured,  then  that 
capture  move  becomes  the  first  move.  If  not,  a  new  subgoal 
THREATEN_KNIGHT  is  activated  that  results  in  a  move  that  threatens  to 
capture  the  knight  on  the  next  move.  In  this  example,  therefore,  the 
first  move  of  a  goal-driven  look-ahead  is  one  that  threatens  the 
knight,  so  that  it  can  eventually  be  captured,  so  that  it  is  no  longer 
defending  the  black  king,  so  checkmate  can  be  achieved.  By  carefully 
considering  objectives  and  goals  at  each  step  in  look-ahead  in  this 
way  a  program  is  able  to  isolate  only  a  few  moves  that  need  to  be 
examined . 
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2.2.2  Goal  Pairing: 


Predicting  an  Adversary's  Goals 


Of  course,  in  order  to  effectively  limit  the  number  of  possible 
move  sequences  to  examine,  the  game  playing  program  must  not  only 
determine  its  own  goals,  but  it  must  be  able  to  guess  the  goals  of  an 
opponent.  Surprisingly  this  is  often  not  nearly  as  difficult  as  might 
be  anticipated.  This  is  because  of  a  general  technique  (often  only 
implicitly  used  by  developers  of  AI  game  playing  programs)  that  will 
be  referred  to  as  'goal  pairing*.  Goal  pairing  is  simply  the  process 
of  identifying  an  adversary's  countergoal  to  each  friendly  goal  or 
subgoal  that  has  been  generated.  In  our  chess  example,  for  instance, 
it  is  reasonable  to  assume  that  White's  goal  of  CAPTUREJKING 
corresponds  to  Black's  goal  of  SAVE_KING  and  furthermore  that  Black 
would  like  to  prevent  the  removal  of  his  knight,  by  preventing  its 
capture.  Therefore,  after  a  white  move  that  threatens  black's  knight, 
black's  move  will  be  one  that  removes  that  threat.  Figure  2-4  lists 
the  White/Black  goal  pairs  that  would  result  from  this  example. 

It  should  be  noted  that  most  of  the  research  on  the  use  of 
goals  and  plans  game  playing  has  been  oriented  toward  developing 
tactical  analyses  programs.  That  is,  the  planners  are  designed  to 

handle  tactical  planning  problems  where  even  'minor'  deviations  from  a 
correct  move  sequence  can  lead  to  failure.  The  next  section  discusses 
some  work  extending  these  techniques  to  high-level  strategic  planning. 
2.2.3  Using  Scenarios  to  Support  Strategic  Planning 

In  many  adversarial  planning  situations,  in  both  game  playing 
and  real-life  conflicts,  human  planners  consider  high-level  strategic 
plans  that  can  not  be  analyzed  by  the  same  type  of  precise 
action-by-action  look-ahead  that  is  characteristic  of  tactical 
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WHITE  GOALS  BLACK  COUNTER  GOALS 

SAVE_KING 
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PREVENT_REMOVE_KNIGHT 

SAVE_KNIGHT 

STOP_THREATEN_KNlGHT 

FIGURE  2-4 

AN  EXAMPLE  OF  GOAL  PAIRING 


analysis.  This  is  because  the  strategic  plan  is  at  such  a  high  level 
that  there  will  usually  be  a  large  number  of  reasonable  move  sequences 
that  are  consistent  with  high-level  strategic  goals.  Or,  put  another 
way,  even  after  goals  and  objectives  are  specified  for  both  sides, 
there  are  too  many  reasonable  plans  of  action  consistent  with  those 
objectives  and  goals  to  be  able  to  consider  them  all.  In  military 
planning,  for  instance,  it  is  not  feasible  to  translate  a  Corps  level 
concept  plan  into  a  precise  plan  of  action  where  all  possible  friendly 

and  enemy  actions  are  taken  into  detailed  consideration  and 
anticipated.  Despite  these  problems,  it  is  clear  that  human  planners 
are  able  to  perform  some  type  of  strategic  planning  or  look-ahead  that 
anticipate  likely  results. 

What  often  makes  this  type  of  strategic  planning  possible  is 
that  usually  all  the  action  sequences  that  follow  the  basic  pattern  in 
a  strategic  plan  will  have  a  number  of  common  positional  side  effects. 
Or,  equivalently,  any  one  sequence  of  actions  that  attains  a  strategic 
plan  is  representative,  strategically,  of  all  the  possible  sequences. 
Consequently,  it  is  possible  to  determine  some  of  the  consequences  of 
a  proposed  strategic  plan  by  exmaining  just  one  specific  plan  of 
action  to  implement  that  plan  and  generalizing  results  to  other 
possible  plans  of  action.  In  Lehner  (1983),  this  is  referred  to  as 
'representative  searching',  in  military  planning  it  is  sometimes 
referred  to  as  'playing  out  a  scenario' . 

A  representative  search  program  for  strategic  planning  in  Go  is 
found  in  Lehner  (1983).  An  example  illustrating  how  this  program 
works  is  provided  below.  Note  that  the  spatial/visual  nature  of 
strategic  plans  in  Go  should  make  this  example  understandable  for 


readers  unfamiliar  with  the  game. 


The  program  began  with  the  position  in  Figure  2-5.  The  White 
stone  at  03  and  04  are  loosely  surrounded  by  the  Black  stones  at  K4 
and  around  Q4.  Black,  the  program,  starts  with  the  goal  of  trying  to 
capture  these  White  stones.  Consequently,  the  representative  search 
program  starts  with  a  top-level  goal  of  CAPTURE  the  White  stones 
around  03,  and  assumes  Black's  countergoal  is  to  SAVE  those  stones. 
In  order  to  capture  a  group  of  stones  in  Go,  one  must  first  surround 

them.  Consequently,  the  first  subgoal  of  CAPTURE  (03)  is  to  SURROUND 
(03),  for  which  White's  counter  goal  is  to  ESCAPE.  Now  in  order  to 
effectively  prevent  ESCAPE,  Black  must  close  up  the  line  between  K4 
and  Q6,  by  placing  stones  in  between  them.  Black  can  do  this  by 

playing  a  sequence  of  stones  from  Q6  to  K4  ( ENCL0SE_RIGHT)  or  by 

starting  at  K4  and  moving  toward  Q6  (ENCLOSE_LEFT) .  The  program 
starts  with  the  former.  This  returns  the  move  06.  After  06  is 

played,  the  only  avenue  of  ESCAPE  for  White  is  between  the  stones  K4 
and  06,  so  White's  assumed  response  is  M5. 

After  the  White  play  at  M5,  attempting  to  enclose  the  White 
stones  by  playing  stones  in  the  K4-06  line  is  not  feasible  because 
White  has  already  broken  through  that  line.  Consequently,  a  new  goal 
of  CREATE_LINE,  to  continue  the  attack  by  creating  a  new  line  of 
attack  is  called.  Also,  since  the  Black  stone  at  K4  is  also  now 
loosely  surrounded,  the  Black  goal  of  SAVE  (K4)  is  also  added, 

resulting  in  an  ESCAPE  subgoal. 

The  conjunction  of  the  Black  CREATE_LINE  and  ESCAPE  goal.® 
results  in  the  move  at  K6.  White  continues  his  own  ESCAPE  by  smashing 
through  the  newly  formed  K6-06  line  with  a  play  at  M7,  at  which  point 
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White  has  successfully  escaped,  because  CREATE_LI NE  cannot  build  a  new 
attack  line.  However,  also  at  this  point  the  representative  search 
program  'notices'  that  in  the  process  of  attacking  the  White  stones  on 
the  right,  he  has  nearly  surrounded  the  White  stone  at  G4. 

Consequently,  he  can  now  switch  direction  and  attempt  to  SURROUND 

(G4 )  . 

There  are  several  things  to  note  about  this  example.  First, 

that  any  sequence  of  reasonable  moves  consistent  with  the  direction  of 

play  depicted  by  with  the  arrows  in  Figure  2-6  (of  which  there  are 
hundreds)  would  have  the  same  positional  consequences,  namely  that 
White  escapes,  but  that  Black  can  start  a  new  attack  in  a  different 
direction.  Consequently,  other  move  sequences  that  attempt  to  achieve 
the  high-level  goal  of  SURROUNDED  (03)  do  not  need  to  be  considered  in 
detail.  Second,  the  fact  that  Black's  original  goal  was  unobtainable, 
but  that  pursuing  it  set  up  the  opportunity  to  obtain  another,  equally 
valuable  goal,  is  not  unique  to  this  example.  It  is  often  the  case 
that  the  primary  value  in  engaging  in  one  strategic  course  of  action 
is  that  it  directs  an  adversary's  resources  and  attention  in  a 
direction  that  it  makes  a  second  follow-on  course  of  action  very 
feasible.  Such  indirect  strategies  and  goals  are  very  important  to 
military  planning,  and  are  precisely  the  type  of  planning  which  this 
type  representative  search  or  scenario  generation  procedure  should  be 
effective . 
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FIGURE  2-6 


DIRECTION  OF  PLAY  FOR  REPRESENTATIVE  SEARCH  SEQUENCE 
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3.0  A  THEORY  OF  ADVERSARIAL  PLANNING 


Overall  the  goal  of  this  research  program  is  to  extend  action 
planning  techniques  into  domains  involving  an  intelligent  adversary. 
The  focus  of  the  first  year  of  this  effort  has  been  to  implement 
initial  version  of  an  adversarial  planner  that  could  serve  as  a 
baseline  system  on  top  of  which  alternative  techniques  for  adversarial 
planning  could  be  implemented  and  evaluated.  Section  3.1  below 
describes  the  baseline  system,  CP/1.0  (Contingency  Planner/Version 
1.0),  which  we  have  developed.  Section  3.2  shows  an  example  of  CP/1.0 

planning  behavior  in  the  game  of  Othello.  Section  3.3  then  examines 

each  of  the  individual  planning  techniques  noted  in  Section  2.0  and 
discusses  how,  in  theory,  they  could  be  embedded  within  the 

adversarial  CP/x  framework. 

3.1  Overview  of  CP/1.0:  A  Baseline  Adversarial  Planner 

CP/1.0  utilizes  two  different  types  of  planning  procedures: 
tactical  planning  and  metaplanning.  Tactical  planning  occurs  whenever 
CP/1.0  must  determine  the  outcome  of  a  well-defined  goal/countergoal 
pairing.  That  is,  tactical  planning  involves  the  process  of 

generating  a  move  tree  to  determine  whether  the  planner's  goal  on  the 
adversary's  countergoal  will  be  achieved,  and  to  discover  some  side 
effects  that  result  from  attempting  to  achieve  a  goal.  Metaplanning, 
on  the  other  hand,  involves  the  use  of  knowledge  about  planning  to 
control  thee  planning  process.  Sections  3.1.1  and  3.2.1  below  describe 
each  of  these  planning  procedures. 
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3.1.1  CP/1.0  Tactical  Planning 

Like  most  planners,  CP/1.0  treat3  planning  as  a  problem  in  goal 
tree  formation.  Described  below  are  the  type  of  goal  trees  CP/1.0 
generates  in  performing  a  tactical  search  and  how  it  goes  about 
generating  then. 

Contingency  Goal  Trees  -  Within  CP/1.0,  plans  are  represented  using  a 
general  formalism  called  a  Contingency  Goal  Tree  (CGT) .  CGTs  are 
similar  to  the  goal  tree  used  in  single  agent  action  planning,  with 
the  important  difference  that  each  node  in  the  tree  include  both  a 
planner's  goal  and  an  adversary's  assumed  countergoal.  Figure  3-1 
shows  a  possible  CGT  for  a  single  move  sequence  leading  to  a  draw  for 
White  in  the  chess  position  show  in  Figure  3-2.  CP/1.0  atempts  to 
solve  adversarial  planning  problems  by  generating  multiple  CGTs  that 
combine  to  form  a  set  of  contingency  plans  against  each  of  the 
reasonable  options  available  to  an  adversary.  In  a  game,  such  as 
chess,  the  set  of  terminal  nodes  in  the  CGTs  combine  to  form  a  move 
tree.  CP/1.0  accepts  as  input  any  incomplete  CGT  and  attempts  to 
generate  a  set  of  expanded  CGTs  that  represent  contingency  plans  for 
achieving  the  top  goal  in  the  input  CGT.  Consequently,  CP/1.0  will 
either  return  a  set  of  CGTs;  or  NIL  if  the  top  goal  cannot  reasonably 
be  achieved.  To  solve  a  planning  problem,  CP/1.0  uses  the  following 
basic  procedures  for  generating  CGTs. 

Goal-driven,  Depth-first  CGT  Expansion  -  Given  an  incomplete  CGT, 
CP/1.0  will  expand  the  CGT  in  a  recursive  depth-first  manner,  it  will 
begin  by  identifying  the  first  node  in  the  input  CGT  that  contains  "a 
goal  pair  for  which  a  well-defined  action  is  not  defined  and  will 
process  the  goal  for  the  side  on  the  move. 
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DRAW  -  WIN 


(For  White) 


(For  Black) 


[OR  NOT(Q(BP) )  Q(WP)]-[AND  Q(BP)  NOT(Q(WP))] 


[OR  CAP (BP)  Q(WP)]-[AND  Q(BP)  CAP(WP)] 


[THREATBOTH  CAP(BP)  Q(WP)]-[AND  Q(BP)  CAP(WP)]  Q(WP)-CAP(WP) 


MVT0(K,G7)-NIL  MVTO(K,BP  WP)-MVTO(BP,h1 )  MVTO(K,WP)-HVTO(K.WP) 


HIL-MVTO(BP.hH)  MVTO(K, f 6)-NIL  NIL-MVTO(BP, h3) 

/ 

MVTO(K,e6)-NIL  KIL-MVTO(K,b6)  MVTO(K,d7)-NIL 


Q(  )  =  Queen  pawn 
CAP (  )  =  CAPTURE 

BP  =  Black  Pawn 

V7P  =  White  Pawn 


FIGURE  3-1 

ILLUSTRATIVE  CONTINGENCY  GOAL  TREE 
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CP/1.0  enters  a  search  problem  with  a  top-level  goal-countergoal 


pairing  and  a  possible  side  effects  list  (described  below) . 
Depending  on  the  position,  processing  of  the  'present*  goal  (usually 
the  goal  most  recently  added  to  the  CGT)  of  the  side  on  the  move  will 
result  in  the  generation  of  a  pair  of  subgoals,  which  are  then  added 
onto  the  CGT,  or  it  will  result  in  the  generation  of  a  move.  If  a  new 
goal  pair  is  added  to  the  CGT,  then  the  new  present  goal  of  the  side 
on  the  move  is  processed  to  produce  a  new  subgoal  pair  or  move.  When 
a  move  is  proposed,  it  is  placed  on  the  hypothetical  board.  The  most 
recently  added  goal  for  the  new  side  on  the  move  becomes  the  present 
goal  which  is  processed  to  see  if  a  new  subgoal  pair  or  move  can  be 
generated . 

Processing  of  the  present  goal  involves  reading  in  a  'goal 
object*  from  a  separate  file  and  executing  the  procedures  attached  to 
the  goal  object.  Goal  objects  are  simply  structures  containing  data 
and  functions  acting  on  this  data.  They  interface  with  the  particular 
problem  environment  through  four  functions.  'Subgoal'  returns  a  list 
of  subgoal(s)  that  is  (are)  currently  most  appropriate.  'Countergoal' 
examines  the  environment  and  returns  a  list  of  suitable 
countergoal ( s) .  'Failed'  tests  if  the  goal  in  the  present  position 
has  clearly  failed.  'Succeeded'  tests  if  the  goal  in  the  present 
position  has  already  succeeded.  'Feasible'  quickly  tests  the 
feasibility  of  a  goal  and  returns  true  if  the  goal  could  be  feasible 
in  the  current  environment.  'Action'  updates  the  enviornment  as  a 
function  oft the  goal/countergoal  pairing.  . 

Processing  of  an  instantiated  goal  object  for  the  side  on  move 
will  generate  an  assumed  countergoal  for  the  opposing  side,  along  with 
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one  of  the  following: 

1.  an  update  of  the  hypothetical  world,  after  which  CP/1.0 
calls  a  domain  specific  utility  to  determine  which  side 
moves  next; 

2.  a  single  subgoal,  which  is  added  to  the  CGT  and  is  then 
processed  as  the  new  present  goal; 

3.  an  incomplete  subtree,  usually  specifying  a  sequence  of 
subgoals,  of  which  the  first  subgoal  is  processed  as 
the  new  present  goal  after  the  entire  subtree  is 
added  to  the  CGT; 

4.  a  NIL  if  processing  of  the  present  goal  does  not  result 
in  an  action,  subgoal  or  subtree,  in  which  case  the 
antecedent  node  for  the  side  on  the  move  is  once  again 
processed  as  the  new  present  goal,  thereby  starting  a 
new  branch  of  the  CGT. 

5.  A  'failed'  or  'succeeded',  which  is  similar  to  No.  4 
above  except  that  instead  of  moving  to  an  antecedent 
node,  a  move  backup  must  occur  as  described  in  the 
subsection  below. 

Goal-driven  backup  -  An  individual  move  sequence  terminates  whenever 
either  the  planner's  or  adversary's  top-level  goal  is  clearly 
obtainable.  Obtaining  the  top  goal,  however,  does  not  necessarily 
imply  that  the  move  sequence  is  a  success.  A  move  sequence  may  result 
in  a  number  of  unanticipated  side  effects  that  result  in  providing 
the  opposing  side  with  new  opportunities.  For  instance,  if  the 
planner  enters  a  search  problem  with  a  SAVE(X)  goal,  paired  with  an 
adversary's  CAPTURE (X)  countergoal,  a  particular  sequence  may  result 
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in  the  planner  successfully  saving  X,  but  the  situation  has  changed 
such  that  the  adversary  now  has  a  new  target,  Y,  to  pursue.  It  is  now 
feasible  for  the  adversary  to  attempt  to  CAPTURE (Y)  instead.  In 
CP/1.0,  unanticipated  side  effects  are  defined  as  new  opportunities, 
which  in  turn  are  defined  as  new  goals  to  pursue  that  were  not 

feasible  in  the  original  position. 

In  order  to  find  new  goals,  CP/1.0  engages  in  a  sequence  of 
'information  searches.'  At  the  end  of  a  move  sequence  where  one  side 
achieved  its  initial  goal,  CP/1.0  iterates  through  a  set  of  recursive 
calls  to  CP/1.0,  with  each  of  the  goals  in  a  'possible  side  effects' 

list,  to  try  to  find  a  way  to  continue  play  for  the  opposing  side. 

The  type  of  move  backup  that  will  occur  depends  on  whether  or  not 

there  exist  new  goals  for  the  opposing  side. 

Whenever  processing  of  the  present  goal  returns  a  NIL,  and  CP/1.0 
cannot  move  up  to  an  antecedent  goal  (e.g.,  when  it  is  the  top  goal); 
or  when  it  returns  a  'failed',  a  backup  on  the  proposed  move  sequence 
must  take  place.  In  CP/1.0  the  procedure  for  determining  how  far  to 
backup  is  goal-driven  and  proceeds  according  to  the  following  three 
steps : 

1.  iterate  through  a  sequence  of  information  searches 
on  the  position,  by  recursively  calling  CP/1.0,  to 
identify  new  goals  that  can  be  pursued  by  the 
failing  side; 

2.  based  on  the  results  of  the  information  searches, 

identify  the  first  node  in  the  CGT  (assuming  a  - 

depth-first  ordering  of  nodes)  that  is 
impacted;  and 
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3.  remove  all  nodes  that  were  generated  after  the 
impacted  node  (which  automatically  includes 
the  moves  identified  in  the  terminal  nodes) , 
modify  the  impacted  node  through  a  conjunction 
or  disjunction  of  new  goals,  and  continue  the 
CGT  generation  process. 

The  information  searches  in  1.  proceed  as  described  above. 
Regarding  2.  and  3.,  if  the  information  searches  do  not  discover  new 
goals,  then  the  only  node  in  the  CGT  that  is  clearly  impacted  is  the 
one  that  directly  generated  the  most  recent  move  for  the  side  that 
failed.  For  the  side  on  the  move,  the  goal  is  modified  to  be  a 

conjunction  of  tha*  ^oal  and  NOT [MOVE (X) ) ,  where  MOVE(X)  is  the  move 
that  failed.  Al i  nodes  added  to  the  CGT  after  this  modifified  goal 
are  removed  a^d  CGT  expansion  continues  as  before. 

If  trie  information  searches  do  discover  unanticipated  side 

effects  (i.e.,  new  goals  to  consider),  then  it  is  necessary  to 
discover  which  nodes  in  the  CGT  the  new  goal  interacts  with.  That  is, 

for  each  goal  in  the  CGT,  it  needs  to  be  determined  if  the  discovery 

of  this  new  opportunity  would  affect  how  the  planner  should  go  about 
crying  to  achieve  that  goal.  Since  goal  objects  carry  with  them  lists 
of  possible  side  effects,  it  is  a  matter  of  selecting  the  first  goal 
in  the  CGT  that  has  the  discovered  goal  on  its  side  effect  list. 

Frequently,  it  is  assumed  that  a  newly  discovered  goal  impacts  the  top 
goal  in  the  CGT,  in  which  case  all  generated  nodes  in  the  CGT  are 
removed  and  the  top  goal  is  modified  to  be  a  conjunction  or 

disjunction  of  the  original  top  goal  with  the  new  goal.  However,  in 
various  domains,  such  as  some  war  games,  there  may  be  a  number  of 
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independent  areas  of  local  conflict,  where  a  discovery  of  local  side 
effects  clearly  do  not  impact  overall  planning. 

3.1.2  Metaplanning  in  CP/1.0 

The  metaplanning  facility  in  CP/1.0  is  a  general,  extendable 
facility  for  deciding  what  planning  strategies  to  use.  Through  the 
use  of  domain  specific  pattern  matching  routines,  it  can  be  used  to 
select  a  top-level  goal  pair  for  a  contingency  goal  tree.  It  can  also 
be  used  to  select  between  the  tactical  planning  mechanism  described  in 
SXection  3.1.1  and  any  other  planning  mechanisms  that  may  be  provided. 
Other  planning  mechanisms  will  probably  be  most  useful  in  the  opening 
moves  of  a  game  like  Chess,  where  a  number  of  standard  book  openings 
are  used,  and  in  the  final  moves  of  a  game  like  Othello,  where  there 
are  few  possible  moves  leading  to  widely  varying  outcomes. 


The  metaplanning  facility,  like  the  tactical  planning  facility. 


uses  a 

type  of 

goal 

objects . 

However,  unlike  the  tactical 

planner , 

the  goal 

objects 

are 

not  paired  because  the  metaplanner 

does  not 

attempt 

to  match 

the 

planning 

mechanism  of  the  opponent. 

Like  the 

tactical 

planner , 

each 

metagol 

object  contains  a  feasibility  test. 

Rather  than  a  list  of  possible  subgoals,  the  metagoal  objects  contain 
a  list  of  planning  actions  to  be  taken  in  sequence  to  achieve  the 
goal.  Examples  of  types  of  planning  actions  are  contingency  planning 
using  a  specific  top-level  goal  pair  and  exhaustive  search.  Each 
metagoal  object  may  also  include  an  alternate  metagoal  object  to  be 
tried  if  the  first  fails. 

The  unetaplanner  works  in  a  very  straightforward  manner.  When 
it  is  called,  it  is  given  an  initial  metagol  object  to  attempt.  It 
first  uses  the  feasibility  test  to  assure  that  the  plan  outlined  in 
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the  frame  is 

reasonable  in 

the 

g  i  ven 

situation. 

If 

it  is , 

the 

metaplanner  attempts 

to  use 

the 

first 

planning 

action 

from 

the 

planning  action 

list . 

The 

metaplanner 

continues  to 

use  the  plann 

ing 

actions  on  the 

list 

until 

the  list  is 

exhausted  or 

until 

one  of 

the 

planning  actions  fails.  If  a  planning  action  fails  or  the  metagoal  is 
not  feasible,  the  metaplanner  attempts  to  process  the  alternative 
metagoal  frame  in  the  same  manner  if  processed  the  original. 

3.1.3  Summary  of  CP/1.0 

Overall,  CP/1.0  implements  an  approach  to  tactical  planning 
that  incorporates  the  goal-driven  AI  game-playing  techniques  discussed 
in  Section  2.2.  In  particular,  the  tactical  planning  facility 

incorporates  the  same  techniques  found  in  tactical  planners  for  Chess 
(Berliner,  1978);  Pitrat,  1977;  and  Wilkins,  1979),  and  Go  (Reitman 
and  Wilcox,  1979).  The  facility  to  search  for  unanticipated  side 
effects  can  be  used  to  generate  the  type  strategic  planning  behavior 
discussed  in  Lehner  (1983) .  Unfortunately,  because  of  the  limited 
nature  of  our  initial  test  domain  (the  game  of  Othello).  This  later 
capability  has  not  been  significantly  tested. 

What  is  unique  about  CP/1.0  is  not  so  much  what  it  does,  but 

rather  how  it  does.  First,  the  CP/1.0  software  is  generic,  which 
makes  it  suitable  for  application  in  multiple  domains.  Previous 

systems  that  have  shown  adversarial  planning  capabilities  were 

entirely  domain  specific,  i.e.,  written  as  game  playing  programs. 
Second  CP/1.0  utilizes  a  formalism  for  representing  plans,  CGTs,  that 
is  a  generalization  of  the  goal  tree  formalism  found  in  AI  action 
planning.  Consequently,  both  AI  action  planning  and  AI  game-playing 
techniques  can  in  theory  be  incorporated  into  the  CP/x  framework.  The 
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CP/x  framework  therefore  provides  the  opportunity  to  merge  these  two 
sets  of  techniques  into  the  combined  area  that  we  have  called 
adversarial  planning. 

An  example  of  CP/1.0  planning  is  found  in  Appendix  A. 

3. 2  Advanced  Adversarial  Planning  Techniques 

The  overall  goal  to  this  research  program  is  to  extend  action 
planning  techniques  to  problems  involving  planning  against  an 
intelligent  adversary.  Section  2.0  discussed  single  agent  planning 
techniques  that  could  also  be  appropriate  for  adversarial  planning 

prcbl  0IH  S  •  S9Ct  I  on  3 . 1  prsssnt  nnr  int  i  t  isl  Kagol  i  no  nl  ppm’  nn 
system,  CP/1,0,  that  provides  a  testbed  for  examining  alternative 
techniques  for  adversarial  planning.  In  this  section  each  of  the 
advanced  action  planning  techniques  noted  in  Section  2.1  are  discussed 
from  the  perspective  of  how  they  might  be  incorporated  within  the 
general  CP/x  framework. 

3.2.1  Goal-Driven  Adversarial  Planning 

As  discussed  in  Section  2.1,  action  planning  techniques  are 
generally  goal-driven.  Planning  is  usually  treated  as  a  problem  in 
goal  tree  formation.  The  same  is  true  of  the  CP/x  approach.  In 
particular,  we  have  extended  the  concept  of  a  goal  tree  to  that  of  a 
contingency  goal  tree.  A  CGT  is  a  generalized  goal  tree  in  as  much  as 
if  a  CGT  did  not  include  the  adversary's  goal,  it  would  contain  the 
same  information  as  a  simple  goal  tree.  In  the  same  way  that  action 
planners  treat  planning  as  a  problem  in  goal  tree  formation,  CP/1+0 
treats  adversarial  planning  as  a  problem  in  contingency  goal  tree 
formation . 
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3.2.2  Hierarchical  and  Parallel  Adversarial  Planning 

As  discussed  in  Section  2.1,  hierarchical  planning  involves  a 
planning  process  where  goals  are  put  in  priority  order,  so  that  the 
more  important  goals,  <i„e.#  the  goals  that  correspond  with  major 
steps  of  a  plan)  are  worked  out  first  and  less  important  goals,  (i.e., 
the  details),  are  considered  later.  In  CP /x  framework,  hierarchical 
planning  could  also  occur.  In  the  situation  where  higher  levels  of 
planning  abstraction  are  defined,  this  would  work  as  follows. 

Recall  that  in  CP/1.0  depth  first  planning,  (i.e.,  subgoal 
generation)  continues  until  it  gets  to  the  point  where  there  exists  a 
utility  for  updating  the  hypothetical  world  for  the  current 
goal/countergoal  pairing.  In  the  game  of  Othello,  this  simply 
occurred  at  the  level  of  a  move-nil  pairing.  For  a  domain  in  which 
there  exist  domain  specific  utilities  for  updating  the  hypothetical 
world  at  different  levels  of  goal/countergoal  pairs,  then  CP/x  can 
plan  at  different  levels  of  abstraction.  First,  CP/x  would  plan  at 
the  most  general  level  of  abstraction  by  engaging  in  depth  first 
planning  until  it  reaches  the  first  set  of  world  update  utilities. 
This  would  result  in  a  set  of  high-level  contingency  plans.  Then, 
using  these  high  level  contingency  goal  trees  as  the  input  CGTs,  CP/x 
would  continue  to  expand  the  CGTs  by  continuing  the  depth  first 
subgoal  generation  process  beyond  the  first  world  update  utility 
encountered  and  stopping  at  the  second.  CP/x  would  do  this 

recursively  for  all  defined  levels  of  abstraction. 

Of  course,  in  order  to  do  this  type  of  hierarchical  planning,  the 
domain  in  which  CP/x  is  applied  requires  that  these  update  utilites 
can  in  fact  be  defined.  In  games  such  as  Othello,  Chess,  and  Go, 
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generating  such  utilities  is  not  possible.  However,  in  domains  such 
as  some  war  games,  utilites  may  be  defined  for  different  levels  of 
conflict  (e.g.,  CORPS,  Division,  Battalion). 

With  regard  to  parallel  planning,  no  explicit  techniques  have 
been  identified  that  can  incorporate  parallel  planning  into  the  CP/x 
adversarial  planning  environment.  However,  in  the  same  way  that  a 
simple  goal  tree  can  be  generalized  to  include  parallel  branches,  it 
is  reasonable  to  assume  that  a  contingency  goal  tree  can  also  be 
generalized  to  include  parallel  branches. 

3.2.3  Using  Skeleton  Plans  in  Adversarial  Planning 

In  action  planning,  this  type  of  planning  involves  the  use  of 
stored  skeletal  plans  that  outline  a  general  sequence  of  steps  for 
solving  problems  in  a  variety  of  problem  areas.  Skeletal  plans  are 
usually  stored  in  the  form  of  partially  complete  goal  trees.  In  the 
case  of  adversarial  planning,  skeletal  plans  can  be  stored  in  the  form 
of  partially  complete  CGTs .  Since,  CP/x  accepts  as  input  a  partial 
CGT  of  any  form,  (i.e.,  any  part  of  the  tree  can  be  left  out)  then 
skeletal  planning  can  occur  in  a  variety  of  ways.  For  example,  a 
skeletal  plan  may  have  just  the  top  layers  of  the  CGT,  with  both  the 
friendly  and  adversary  countergoals,  defined.  On  the  other  hand,  a 
skeletal  plan  may  involve  a  contingency  goal  tree  with  just  the 
friendly  goals  identified  and  the  adversarial  goals  left  uncertain. 
In  the  latter  case,  then,  we  would  have  prestored  the  major  sequence 
of  actions  the  planner  would  take  and  CP/x  would  try  to  fill  in  the 
adversary' s '-countergoals. 


3.2,4  Opportunistic  Planning  in  Adversarial  Domains 


Opportunistic  planning  as  discussed  in  Section  2.0  is  an 
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approach  to  planning  that  is  characterized  by  flexible  planning 
control  structure  that  allows  development  of  a  plan  in  both  bottom-up 
and  top-down  manner.  At  present,  CP/x  is  not  compatible  with  this 
type  of  flexible  control  structure.  However,  the  representative 
search  technique  can  be  emulated  within  the  CP/x  approach.  As  was 
discussed  in  Section  2.1,  representative  searching  does  exhibit  a 
number  of  behaviors  that  are  similar  to  that  of  opportunistic 
planning . 

3.2.5  Metaplanning  in  Adversarial  Domains 

As  discussed  in  Section  3.1,  metaplanning  is  incorporated 
within  the  CP/x  framework  through  the  use  of  metagoals.  Consequently, 
metaplanning  is  one  advanced  action  planning  technique  that  has 
already  been  incorporated  into  the  CP/x  framework.  Unfortunately, 
because  of  this  limited  nature  of  our  test  domain  (the  game  of 
Othello)  ,  this  facility  has  not  significantly  tested. 

3.2.6  Adversarial  Planning  in  Uncertain  Environments 

Adversarial  planning  in  uncertain  environments  involves  at 
least  two  dimensions  of  uncertainty.  First,  there  is  the  dimension  of 
uncertainty  about  the  adversary’s  goals.  Second,  there  is  the 
dimension  of  uncertainty  about  the  position  of  adversary  resources. 
In  the  CP/x  framework,  uncertainty  about  the  opponent's  goals  and 
objectives  is  handled  by  generating  contingency  plans  for  each 
possible  goal  and  objective.  One  limit  of  the  existing  CP/1.0 
framework  is  that  there  does  not  exist  a  mechanism  for  limiting  the 
number  of  possible  adversary  goals  or  objectives  that  are  considered ^ 
As  a  result,  in  some  domains  there  may  be  a  combinatorial  explosion  of 
the  number  of  CGTs  that  are  generated.  In  order  to  prevent  this  from 


37 


occurring,  a  deductive  mechanism  should  be  added  that  will  identify 
the  most  likely  adversarial  countergoals  of  each  of  the  friendly 
goals.  Utilization  of  this  deductive  mechanism  should  be  goal 

specific  and  would  be  controlled  with  routines  attached  to  the 
countergoal  slot  in  the  goal  objects  in  a  CP/x  knowledge  base. 

For  the  second  problem,  where  the  planner  has  a  lack  of  knowledge 
about  tne  position  or  nature  of  adversary  resources,  there  exist  three 
subproblems  that  need  to  be  solved.  First,  there  is  the  problem  of 
simply  deducing  or  making  a  best  guess  as  to  where  and  what  those 
resources  are.  Second,  there  is  the  problem  of  planning  to  collect 
information  about  uncertain  resources.  Third,  there  is  the  problem  of 
generating  plans  that  take  into  account  alternative  contingencies  in 
the  quantity  or  location  of  resources;  that  is  trying  to  generate 
plans  that  are  robust  against  lack  of  knowledge. 

The  first  problem  is  purely  an  inferencing  problem  and  is  not 
within  the  scope  of  this  research  program.  The  second  problem,  from 
our  present  persepctive,  appears  to  require  only  the  use  of 

information  goals,  (i.e.,  COLLECT_INFORMATION (X) ]  paired  with  an 
adversary's  countergoals  of  preventing  the  collection  of  information. 
Whether  the  adversary  does  that  by  directly  intercepting  our 

information  collection  resources  or  through  deception  tactics,  will  be 
determined  by  the  subgoals  available  to  the  adversary's 
PREVENT_INFORMATION_COLLECTION  countergoal . 

The  third  problem  is  one  which  we  have  not  yet  addressed.  At 
present,  tlje  only  mechanism  that  we  envision  is  one  that  is  similar  t^o 
the  contingency  goal  tree  generation  process,  where  instead  of  having 
alternative  countergoals,  alternative  possible  world  states  are 
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considered.  A  contingency  plan  for  each  one  would  be  developed. 
Although  this  approach  is  theoretically  feasible,  in  most  cases  it 
will  probably  lead  to  a  combinatorial  explosion  in  the  search  space. 


Consequently,  we  need  to  develop  a  more  elegant  approach. 

3.2.7  Dealing  with  Time  in  Adversarial  Planning 

As  discussed  in  Section  2.1,  planning  systems  that  explicitly 
deal  with  time  are  rare.  There  exist  very  few  if  any  truly 
time-dependent  models  for  planning.  In  the  case  of  adversarial 
planning,  the  problem  is  the  same.  There  do  not  exist  at  present  what 
appear  to  be  good  models  or  techniques  for  incorporating 

time-dependent  outcomes  into  the  adversarial  planning  process.  In  the 
CP/x  framework,  the  best  that  can  be  done  at  the  moment,  is  to  attach 
a  time-required-to-generate-outcomes  to  the  world  update  functions. 
What  that  means  is  that  when  there  exists  a  local  conflict,  the 
utility  for  updating  the  world  state  can  also  have  incorporated  within 
it  an  estimate  as  to  the  time  required  to  resolve  that  conflict. 
Given  this  approach,  CP/x  can  estimate  time  required  to  execute  one 
versus  another  contingency  plan.  This  type  of  time-dependent  world 
update  is  reasonable  in  domains  where  all  actions  occur  in  a  linear 


sequence , 


However,  for  parallel  planning,  which  will  have 


parallel-with-respect-to-time  actions,  it  becomes  significantly  more 
difficult  to  use  this  approach. 

3.2.8  Distributed  Execution  in  Adversarial  Planning 

As  discussed  in  Section  2.1.8,  it  is  sometimes  useful  in 
parallel  planning  to  have  separate  execution  modules  to  execute  ttye 
actions  in  each  of  the  parallel  branches  in  a  plan.  Distributed 


execution  modules  need  to  be  able  to  communicate  and  coordinate.  In 


adversarial  domains,  however,  an  intelligent  adversary  will  attempt  to 
disrupt  this  communication  and/or  coordination.  In  order  to  handle 
that  kind  of  problem  within  the  CP/x  framework,  we  need  to  incorporate 
a  MAI NTAIN_COMMUNICATION  and  a  MAINTAIN_COORDINATI ON  goal  and  assume 
that  the  adversary  has  a  countergoal  of  DISRUPT_COMMUNICATION  and/or 
DISRUPT  COORDINATION.  Each  of  these  maintain  and  disrupt  goals  then 
will  have  subgoals  attached  to  them  that  correspond  to  explicit 
techniques  for  obtaining  these  goals. 

3.2.9  Interactive  Adversarial  Planning 

There  are  a  number  of  ways  that  an  adversarial  planning  system 
such  as  CP/x  can  be  adapted  to  cooperative  man/machine  planning.  One 
approach  that  is  consistent  with  some  existing  interactive  action 
planners,  is  to  modify  the  goal  objects  to  allow  user  inputs  in  the 
subgoal  selection  process.  The  second  approach  is  to  let  the 

adversarial  planner  CP/x  play  the  role  of  a  "devil’s  advocate", 
pointing  out  specific  counterplans  available  to  an  adversary. 
Finally,  a  third,  theoretical  very  interesting  approach  is  one  that 
treats  cooperative  planning  against  an  adversary  as  a  multi-agent 

planning  problem.  In  this  case,  CP/x  must  explicitly  reason  about 

both  the  adversary's  competitive  agent's  goals  and  the  user's  (a 
cooperative  agent)  goals.  This  last  approach  remains  somewhat 

speculative  and  we  are  not  sure  how  to  implement  it. 

3.3.10  Extending  CP/x  to  Multi-Agent  Environments 

CP/x  reasons  about  a  competitive  agent's  goals  and  plans 
through  a  straightforward  process  of  goal  pairing.  Namely  that  every 
time  a  subgoal  is  proposed  and  added  to  a  goal  tree,  the  adversary's 
assumed  countergoal  is  immediately  generated  and  also  added  to  the 
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goal  tree.  Consequently,  wherever  CP/x  needs  to  take  into  account  the 
adversary  actions,  a  complete  goal  tree  representation  of  the 
adversary's  assumed  perspective  is  also  available,  leading  to 
immediate  selection  of  possible  adversary  actions. 

Extending  this  t«o-agent  goal  pairing  process  to  a  more 
general  multi-agent  goal  matching  process  is  straightforward.  To  do 
this  requires  primarily  that 

•  CP/x  itself  be  generalized  to  accept  as  input  the 
top-level  goals  of  any  number  of  agents,  and 

•  The  ' countergoal '  selection  procedures  in  the  goal 
definitions  needs  to  be  generalized  to  generate 
other  goals  for  all  agents,  both  competitive  and 
cooperative . 

Although  a  generalized  CP/x  provides  a  framework  for 
processing  the  goals  of  any  number  of  cooperative  or  competitive 
agents,  it  does  not  necessarily  imply  that  the  generalied  CP/x  will  be 
an  effective  planner  in  this  type  of  environment.  The  quality  of  the 
planning  process  still  depends  on  the  goal  processing  procedures 
defined  in  the  goal  objects.  Specific  techniques  for  selecting 
matching  goals  and  subgoals,  that  are  appropriate  to  the  multi-agent 
environment,  need  to  be  embedded  in  the  goal  objects. 
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4.0  SUMMARY 


According  to  the  original  proposal,  the  goal  of  the  first  year  of 
this  effort  was  to  achieve  the  following  milestones: 

1.  Implement  a  central  planning  control  system  for  adversarial 
planning  that  includes  modules  for  controling  goal  genera¬ 
tion,  updating  of  hypothetical  world  states,  determining 
affected  goals  in  a  previsouly  generated  goal  tree,  and 
replanning/backup  procedures. 

2.  Implement  a  rudimentary  version  of  the  CP/x  environment 
that  includes  a  general  ability  to  define  and  develop 
knowledge  bases  that  CP/x  can  access. 

3.  Apply  CP/x  to  at  least  one  problem  domain,  specifically  a 
simple  board  game  simulating  a  war  environment. 

In  general,  these  milestones  have  been  met,  although  the  board 
game  selected  for  testing  CP/1.0  was  Othello  and  not  a  war  game.  In 
fact,  selection  of  an  appropriate  problem  domain  turned  out  to  be  one 
of  the  most  difficult  problems  facing  the  first  year  effort.  This 
difficulty  occurred  because  of  an  inherent  conflict  between  the  need 
for  a  domain  rich  enough  to  effectively  test  CP/1.0  capabilities  and 
the  need  to  minimize  knowledge  engineering  time  so  that  we  could  focus 
our  efforts  on  developing  CP/1.0  itself. 

Othello  is  an  alternating-play  game  that  does  not  require  a  large 
knowledge  base  of  goals  for  a  reasonable  level  of  play,  but  has  never 
been  programmed  with  knowledge-based  search  procedures.  Consequently, 
it  provided  a  good  domain  for  evaluating  CP/1. 0's  search  behavior. 
Most  interesting  war  games,  on  the  other  hand,  were  too  complex  to 
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have  been  a  suitable  year  one  test  domain.  They  would  have  required 
that  a  substantial  amount  of  time  be  dedicated  to  generating  domain 
specific  utilities  and  knowledge  engineering. 

Regarding  future  work,  the  focus  for  the  next  two  years  will  be 
on  systematically  implementing  and  testing  the  various  advanced 
planning  techniques  discussed  in  Section  3.2.  The  immediate  focus 
will  be  on: 

•  testing  the  representative  search  and  metaplanning 
capabilities  that  are  embedded  in  CP/1.0,  but  could 
not  be  satisfactorily  tested  in  the  domain  of  Othello; 

•  implementing  a  facility  for  planning  in  domains  that 
involve  uncertainty,  information  goals,  and  the  use  of 
deception  tactics;  and 

•  implementing  an  automated  hierarchical  planning  capability. 
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APPENDIX  A 


AN  EXAMPLE  OF  CP/1.0  TACTICAL  SEARCH  IN  OTHELLO 


A.0  AN  EXAMPLE  OF  CP/1.0  TACTICAL  SEARCH  IN  OTHELLO 

For  the  board  position  shown  in  Figure  A-l,  CP/1.0  generated  the 
move  tree  shown  in  Figure  A-2.  Figures  A-3  to  A-7  show  the 
contingency  goal  trees  associated  with  each  branch  of  this  move  tree. 
The  specific  goal  objects  that  generated  this  search  are  shown  in 
Appendix  B. 
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FIGURE  A-l 

INITIAL  POSITION  IN  CP/1.0  OTHELLO  SEARCH  EXAMPLE 
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FIGURE  A-2 


MOVE  TREE  FOR  CP/1.0  OTHELLO  SEARCH  EXAMPLE 


White  Moves  First 
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IMRPOVE  POSITION:  PREVENT  (IMPROVE  POSITION) 


IMP  A  CNR:  STOP  A  CNR 


IMP_CNR(0  7  )  :  STOP  CNR  (0  7) 


CNTRL_1_2_AWAY(0  7): STOP  1  2  AWAY(0  7) 


PLAY  (1  5) : NIL  NIL : PLAY (2  6) 


FIGURE  A-3 

FIRST  CONTINGENCY  GOAL  TREE  IN  SEARCH 
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IMPROVE_POSITION: PREVENT  (IMPROVE_POSITION)  + 

IMP  A  CNR: STOP  A  CNR  + 


IMP_CNR  (7  7)  .‘STOP  CNR  (7  7) 


CTRL  1  2  AWAY (7  7 ) : STOP  1  2  AWAY (7  7) 


NIL: PLAY (6  7) 


(+  indicates  goal-pair  kept  from  previous  tree) 


FIGURE  A-4 

SECOND  CONTINGENCY  GOAL  TREE  IN  SEARCH 
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IMPROVE  POSITION' PREVENT (IMPROVE  POSITION)  4 


PLAY  SIDE: STOP  PLAY  SIDE 


NIL: PLAY (5  0) 


(+  indicates  goal-pair  kept  from  previous  tree) 


FIGURE  A-5 

THIRD  CONTINGENCY  GOAL  TREE  IN  SEARCH 
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IMPROVE  POSITION: PREVENT (IMPROVE  POSITION)  + 


PLAY  SIDE: STOP  PLAY  SIDE  + 


(+  indicates  goal-pair  kept  from  previous  tree) 

FIGURE  A-6 

FOURTH  CONTINGENCY  GOAL  TREE  GENERATED  DURING  SEARCH 
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IMPROVE  POSITION: PREVENT ( IMPROVE_POSITION) 


PLAY  SIDE: STOP  PLAY  SIDE  + 


PLAY_SAFE { 7  3 ) : PLAY_SAFE ( 7  3) 


3) :NIL 


FAILED  FOR 
BLACK 


NIL: AND [TURN  OVER (7  3), NOT (PLAY  7  4)] 


(+  indicates  goal-pair  kept  from  previous  tree) 


FIGURE  A-7 

FIFTH  CONTINGENCY  GOAL  TREE  IN  SEARCH 
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APPENDIX  B 


SOURCE  LISTINGS  FOR  CP/1.0  AND  OTHELLO 


B.0  SOURCE  LISTINGS  FOR  CP/1.0  AND  OTHELLO 

The  source  listing  for  CP/1.0,  the  utilities  for  playing 
Othello,  and  the  Othello  goal  objects  are  provided  below.  Since 
CP/1.0  is  an  intermediate  product  that  will  be  significantly 
enhanced  and  modified  during  the  next  two  years  of  this  program,  and 
Othello  is  primarily  a  test  domain  for  debugging  the  CP/1.0 
software,  no  attempt  has  been  made  to  provide  extensive  internal 
commenting  of  the  code. 

Instructions  for  playing  Othello,  using  CP/1.0  are  found  in  the 
Intro. Othello  file  on  the  magnetic  tape  delivered  with  this  report. 
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CONTINGENCY  PLANNER/VERSION  1.0 
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(def  search 
(nlaabda  (firm! 

(prod  (selist  treJs  tree  environoent  tsorf  tiessflad) 
(cond  ((null  (cadr  rare**)) 

(seta  tree  (eeketree  (turdualrair)))) 

(t 

(seta  tree  (eval  (cadr  raraas))))) 

(seta  IreJs  (list  (list  (densve)  (sens**)))) 
retrv 

(seta  tree  (ainback  tree)) 

(cond  ((car  (lastrair  tree)) 

(cond  ((sideffects  rselist) 

(do  retru))))) 

(suitchsides  'deal) 

(return  tree)))) 

(def  ainback 
(laabda  (tree) 

(prod  (neutree  environoenl) 
loop 

(seta  tsorf  nil) 

(seta  new tree  <far_as_POSsible  tree)) 

(cond  ((and  (or  (null  (cur  (laslrair  tree))) 
(ea  tsorf  'failed)) 

(can.tria  nealret*)) 

(seta  treJs  (eddr  treJs)) 

(seta  tree  (tri*  neutree)) 

(suitchsides) 

(do  loop)) 

((and  (ea  tsorf  'succeeded) 

(can-triel  neutree}) 

(seta  treJs  (c dr  treJs)) 

(seta  tree  (trial  neutree)) 

(do  loop))) 

(return  neutree)))) 

(def  far.as possible 
(laabda  (tree) 

(cpu  environaent  board) 

(prod  {neu.tree) 

(suitchsides  'counterdoal) 

(elauout  tree) 

(prod  nil 
loop 

(suitchsides) 

(seta  neu.tree  (coapleataove  tree)) 
(cond  (rev. tree 

(seta  tree  neu.tree))) 

(and  (or  (eo  tsorf  'succeeded) 

(null  neu.tree)) 

(return)) 

(do  loop)) 

(return  tree)))) 


(def  coapleataove 
(laabda  (tree) 
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(rrod  nil 
loor 

(or  (continue-rlas) 

(return  tree)) 

(seto  tree  (iaerovejteee 
(oval  (teti  (cur  (lastrair  tree)) 

(ouote  action))) 

(do  loor)))) 

(def  iarrove.tree 
(laabda  (tree) 

(cond  ((and  (dreaterr  (lendth  tree)  2) 

(cond  ((all.or_nil  (butlast  tree) 

(listtree 

(iarrove.tree  (lastn  tree))))) 

(t 

(reorror  (currejs  trejs)  (cur  (lastrair  tree))) 

nil)))) 

((null  tsorf) 

(exrand_tree  tree))))) 


(def  exeand.tree 
(laabda  (tree) 

(cond  ((and  (deti  (cur  (toe  tree))  (euote  action)) 

(eval  (deti  (cur  (toe  tree))  'feasible))) 

(seta  tsorf  nil) 

(seta  IreJs  (cons  (list  (denssa)  (densse))  trejs)) 
tree) 

(t 

(cond  ((eval  (deti  (cur  (toe  tree))  'succeeded)) 

(seta  tsorf  'succeeded) 
tree) 

((eval  (deti  (cur  (toe  tree))  'failed)) 

(seta  tsorf  'failed) 
nil) 

(t 

(seta  fheve  (all.or.nil  tree 

(select.sub  (toe  tree)))) 

(cond  (thave 

(aeeend  (list  'tree 

(list  (car  (toe  tree)) 

(lastn  thave))) 

(butlast  (eddr  thave))))))))))) 


(def  select.sub 
(laabda  (earaa) 

(prod  (current  curlist  res) 

(seta  curlist  (set. sub  (eval  (deti  (cur  earaa)  'subdoal)) 
(det  (currejs  treJs)  (cur  earaa)))) 
(seta  curlist  (subset  '(laabda(k) 

(eval (deti  k  'feasible))) 
curlist)) 

lour 

(seta  current  (car  curlist)) 

(seta  curlist  (edr  curlist)) 

(euteroe  (currejs  trejs) 
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(cons  current  (jet  (curreus  IreJs)  (ctif  para*))) 

(cur  pares)) 

(co «d  ((and  current 

(null  (seta  res 

(exrand.tree 

(aaketree  (countereair  current 

(count  paras))))))) 

(jo  loop))) 

(return  (cond  (res 

(list  res  nil)) 

(t 

(list  res))))))) 

(def  all_or-nil 
(laabda  (listl  list2) 

(cond  ((and  (and  listl  list2) 

(not  (eaual  list2  (auote  (nil))))) 

(append  listl  list2))))) 


(def  aaketree 
(lexer  (nears) 

(list  'tree  (list  (ars  1) 

(cond  ((sreatere  nears  1) 
(ars  2))))») 

(def  lasteair 
(laabda  (tree) 

(cond  ((eoual  (car  tree)  (auote  tree)) 
(lasteair  (lastn  tree))) 

(t 

tree)))) 


(def  butlast 
(laabda  (list) 

(cond  ((or  (null  list) 

(eo  (lensth  list)  D) 

nil) 

(t 

(cons  (car  list) 

(butlast  (cdr  list))))))) 


(def  sideffects 
(laabda  (eselist) 

(seta  xxxx  nil) 

(erinc  'searchins  for  side  effects') 

(tereri) 

(subset  (ouote  (laabda  (k) 

(possible  (aaketree  (counterpair  k  nil))))) 

eselist))) 


(def  possible 
(laabda  (tree) 

(pros  (neu-tree) 

(svitchsides  'Seal) 
(pros  nil 
looe 
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(switchsides) 

(seta  new. tree  (coaeleataove  tree/) 

(cund  (new.tr ee 

(seta  tree  new.tree))) 

(and  (null  new.tree) 

(return)) 

(so  looe)) 

(cond  ((eo  (side  'doal) 

(return  tree)) 

(t 

nil))))) 

(def  switchsides 
(lexer  (near) 

(cond  ((or(and(e«  near  1) 

(ee  (art  1)  'doal)) 

(and(not(ea  near  1)) 

(eoual  tside  'countertoal 5 ) ) 

(def  cur 

(laabda  (earat) 

(caar  earaa))) 

(def  count 

(laabda  (earaa) 

(cadar  earaa))) 

(def  currejs 

(laabda  (list) 

(caar  list))) 

(def  addreJs 

(laabda  (reject) 

(sete  IreJs 

(list  (list  (cons  reject 

(caar  treJs)) 
(cadar  treJs)) 

(cadr  treJs))))} 

(def  coittereair 

(laabda  (subdoal  cearent) 

(list  subdual 

(countertoal  subdoal  cearent)))) 
(seta  curs ide  (auote  while)) 

(seta  tside  'doal)) 

(t 

(def  cur 

(laabda  (earaa) 

(cadar  earaa))) 

(def  count 

(laabda  (earaa) 

'  (caar  earaa))) 

(def  curreJs 

(laabda  (list) 

(cadar  list))) 

(def  addreJs 

(laabda  (reject) 

(seta  treJs 

(list  (list  (caar  treJs) 

(cons  reject 

(cadar  treJs))) 
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(cadr  IreJs))))) 

(def  counterrair 

(laabda  (subSoal  crarent) 

(list  ( count*  rSoal  subsoal  crarent) 

fuhSOil))) 

(sets  curside  (euote  black)) 

(seta  tside  'countersoal))))) 


(def  countersoal 
(laabda  (sob  crarent) 

(car  (int  (aval  (seti  sub  'countersoal)) 

(aval  (sail  crarent  'sub_not_oruaove)))H) 

(def  int 
(laabda  (si  s2) 

(cood  ((and  si  s2) 

(arris  'arrend  (earcar  '(laabda  (k) 

(listcar  (aaaa  k  si))) 

s2))) 

(si) 

(s2))» 


(def  listcar 
(laabda  (list) 

(cond  ((null  list) 
nil) 

(t 

(list  (car  list)))))) 


(def  eakeSoal 
(aacro  (call) 

(rutrror  (cadr  call)  't  'feasible) 

(cond  ((  not  (aeao  (cadr  call)  tearsoals)) 

(seta  reresoals  (cons  (cadr  call)  rereSuals)))) 

(erod  (soalnaae  cur  list) 

(seta  Soalnaee  (cadr  call)  cur  (caddr  call)  list  (cdddr  call)) 
(rros  nil 
loor 

(or  cur  (return)) 

(ruton  soalnaae  cur) 

(seta  cur  (car  list)) 

(seta  list  (cdr  list)) 

(So  looe)) 

(return  nil)) 

(list  (euote  rutrror) 

(list  (euote  euote) 

-  (cadr  call)) 

(euote  (euote  Soal>) 

(euote  (euote  tyre))))) 


(def  ruton 
(aacro  (call) 

(list  (euote  rutrror) 

(cadr  call) 

(list  (euote  euote) 

(cadr  (aval  (caddr  call)))) 
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(list  (auote  ouote) 

(car  (eval  (caddr  call))))))) 

(def  deti 

(laabda  (ata  pwI 

(cond  ((null  at*) 
nil) 

(t 

{coni  ((and  (not  (aeaa  at*  reradoals)) 

(not  (»eao  at*  teardoals))) 

(ins tan  at*))) 

(del  at*  prop))))) 

(def  dener 
(laabda  (ata) 

(cond  ((del  ata  (auote  dener))) 

(t 

(put* roe  ata 

(iaplode  (toslash  (explode  ata))) 

(ouole  dener)))))) 

(def  seecf 
(laabda  (ata) 

(cond  ((det  ata  (auote  specif))) 

(t 

(euterop  ata 

(iaelode  (taklst  (froaslash  (explode  ala)))) 
(auote  specif)))))) 

(def  aakefora 
(aacro  (call) 

(list  (ouote  putprop) 

(list  (ouote  Quote) 

(cadr  call)) 

(list  (ouote  Quote) 

(cddr  call)) 

(guote  (ouote  fora))))) 

(def  ins  tan 
(aacro  (call) 

(and  (null  (det  (dener  (eval  (cadr  call)))  'fora)) 

(princ  'undefined  fora')) 

(seta  teaedoals 

(cons  (eval  (cadr  call)) 
leapdoals)) 

(append  (list  (ouote  aakedoal) 

(eval  (cadr  call))) 

(substit  (seecf  (eval  (cadr  call))) 

(det  (dener  (eval  (cadr  call))) 

(Quote  fora)))))) 

(def  tree 

(laabda  (ite*  1  tok) 

(aaecar  (ouote  (laabda  (k) 

(cond  ((eoual  k  tok) 
ilea) 
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(cond  ((and  k 

(car  k) ) 

(seta  t we 

(iaelode  (areend  (explode  den) 

(lunaklst  (explode  k)))>) 
(rutrrur  leap  den  (iwole  Sorter)) 

(putrror  tear  k  (Quote  srecif)) 

(return  teep)) 

(t 

(return  nil)))))) 


(def  firstrair 
(laabda  (tree) 

(cond  ((not  (eeual  (car  tree) 

(<wote  tree)))) 

((caddr  tree) 

(firstpair  (caddr  tree))) 

(t 

(toe  tree))))) 


(def  listtree 
(laabda  (tree) 

(cond  (tree 

(list  tree))))) 


(def  toe 
(laebda  (tree) 

(cadr  tree))) 

(def  neuout 
(laabda  (tree) 

(erinc  'achieve  ') 

(nevout2  tree))) 

(def  neuout2 
(laabda  (tree) 

(princ  (cur  (toe  tree))) 

(cond  ((count  (toe  tree)) 

(erinc  '  without  al"  wind  ') 
(rnnc  (count  (toe  tree))))) 
(tereri) 

(cond  ((dreaterr  (lendth  tree)  2) 
(eriic  *bv  ') 

(nevout2  (lastn  tree)))))) 


(def  sindlethread 
(laabda  (tree) 

(and  (eeual  (car  tree) 

(euote  tree)) 

(or  (eeual  (lendth  tree)  2) 

(and  (eeual  (lendth  tree)  3) 

(sindlethread  (lastn  t*ec>))))>) 

(def  ret. 1  .branch 
(laabda  (tree) 

(cond  ((or  (eo  (lendlh  tree)  2) 

(null  tree)) 
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((not  (sindlethread  (lastn  tree))) 

(append  (butlast  tree) 

(list  ( re*. 1 .branch  (lestn  tree))))) 
<t 

(butlast  tree))))) 

(def  c*n_tria 
(laabda  (tree) 

(prod  nil 
looe 

(cond  ((and  (dead  (lastpair  tree)) 
tree) 

(seta  tree  (rea_l_branch  tree)) 

(do  loop)))) 

(cond  ((or  (sindlethread  tree) 

(null  tree)) 

nil) 

((sindlethread  (lastn  tree)) 

(can-trial  (butlast  tree))) 

(t 

(can_lria  (lastn  tree)))))) 

(def  tria 
(laabda  (tree) 

(pros  nil 
loop 

(cond  ((and  (dead  (lasteair  tree)) 
tree) 

(seta  tree  (rea_l.branch  tree)) 

(do  loop)))) 

(cond  ((not  (sindlethread  (lastn  tree))) 

(append  (butlast  tree) 

(list  (tria  (lastn  tree))))) 

((null  tree) 
nil) 

(t 

(trial  (butlast  tree)))))) 

(def  can-trial 
(laabda  (tree) 

(prod  nil 
loop 

(cond  ((and  tree 

(dead  (lastpair  tree))) 

(seta  tree  (rea.l -branch  tree)) 

(do  loop)))) 

(dreaterp  (lensth  tree)  2))) 

(def  trial 
(laabda  (tree) 

(prod  nil 
loop 

(cond  ((and  (dead  (lastpair  tree)) 
tree) 

(seta  tree  (rea.l. branch  tree)) 

(do  loop)))) 


Nov  2?  13551  1984  crl.O  Pade  10 


B-10 


(cood  ((and  (ee  (lendth  trc«)  3) 

(ee  (lendth  (caddr  tree))  2)) 

(cood  ((null  (c aaadaddr  tree) ) 

(reeeroe  (curreJs  tre«?s)  (cadaadr  tree)) 

(take tree  (list  (caaadr  tree) 

(Soalinst  'andnot 

(list  (cadaadr  tree) 

(cadaadaddr  tree)))))) 

(t 

(reerror  (curreJs  treJs)  (caaadr  tree)) 

(eaketree  (list  (doalinst  'amiuut 

(list  (caaadr  tree) 

(caaadaddr  tree))/ 
(cadaadr  tree)))))) 

(<re  (lendth  tree)  2) 

'(tree  ((nil  nil)  nil))) 

(t 

(arrend  (butlast  tree) 

(list  (trial  (lastn  tree)))))))) 

(def  dead 
(laebda  (rair) 

(not  (or  (seti  (cur  rair)  'action) 

(deti  (count  rair)  'action))))) 

(def  r lauout 
(laebda  (tree) 

(cood  ((dreaterr  (lendth  tree)  2) 

(earc  (euote  rlayoul) 

(cddr  tree))) 

((lessr  (lendth  tree)  3) 

(cood  ((null  (cadar  (tor  tree))) 

(eval  (Seti  (caar  (tor  tree))  'action)) 

(suitchsides  'counterfoil)) 

((null  (caar  (tor  tree))) 

(evil  {deti  (cadar  (tor  tree))  'action)) 

(suitchsides  'deal)))) 

(t 

(r layout  (caddr  tree)) 

(rlayout  (edddr  tree)))))) 

(def  rlavboard 
(laebda  (tree) 

(cood  (<ea  (lendth  tree)  2) 

(cood  ((deti  (caaadr  tree)  'urdateaction) 

(evil  (deti  (caaadr  tree)  Vdateaction)) 
t))) 

(t 

(soee  'rlavboard  (cddr  tree)))))) 

(def  taklst 
(laebda  (list) 

(arrend  (cons  '1(1  (earcar  (euote  (laebda  (k) 

(cond  ((  eeual  t  'HI)  ">  I) 
(t 

ki))> 


list)) 
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(euote  (1)1))))) 


(def  tunaklst 
(laabda  (list) 

(■war  (ouote  (laabda  (k) 

(cond  ((mm  k  (ouote  (1(1  1)1))) 
'l/D 

«eoual  'Ilk) 

MM) 

(t 

k»» 

list))) 

(def  substit 
(laabda  (list  fora) 

(eras  (tear) 

(seta  tnr  (cdr  fore)) 

(uk  (suote  (laabda  (tic  Uc) 

(seta  tear 

(tree  tic  tear  tac)))) 

list 

(car  fora)) 

(return  tear)))) 

(def  subset 
(laabda  (funct  list) 

(do  ((cur  (car  list) (car  list)) 

(s)) 

((null  list) 
s) 

(seta  list  (cdr  list)) 

(cond  ((arris  funct  (list  cur)) 

(seta  s  (arrendl  s  cur))))))) 


(def  avers 
(laabda  (funct  list) 

(do  ((cur  (car  list)  (car  list))) 

((or  (null  list) 

(not  (aval  (list  funct  'cur)))) 
(cond  ((null  list) 
t))> 

(seta  list  (cdr  list))))) 

(def  soae 

(laabda  (funct  list) 

(do  ((cur  (car  list)  (car  list))) 

((or  (null  list) 

(eval  (list  funct  'cur))) 

(cond  (list 
list))) 

(seta  list  (cdr  list))))) 


(def  sct.sub 
(laabda  (seti  set2) 

(aarc  '(laabda  <k) 

(seta  setl  (ellbut  k  sell))) 
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sel2> 

sett)) 


.  (def  ness 

(laabda  (list) 

(cood  «*nd  <*ull  ness  Has) 

(tese  (cur  (caadar  (last  tree)))  list)) 

(seU  nessflad  t)) 

(t 

(seta  nessflad  nil))))) 

( BAe fort  or  (doall  doal2) 

(subdoal  '(doall  doal2)) 

(sub_not_on_»ove  ‘(nil)) 

(counterdoaHlist  (doal ins t  'and  (list  (car  (deti  doall  'counterdual)) 

(car  (deli  doal2  'coufilerdoal))))))) 

(sakeforo  and  (doall  doal2) 

(subdoal  '(doall  doal2)) 

(sub.not.on_Mve  '(doall  doa!2)) 

(counterdoal  (list  (doalinst  'or  (list  (car  (deti  doall  'cuunteisual)) 

(car  (deti  doal2  'counterdoal))))))) 

(aakefore  andnol  (doall  doal2) 

(subdoal  (allbut  'doal2  (eval  (deti  'doall  'subdoal)))) 

(sub-nol-on-aove  (eval  (deli  'doall  'sub.riot_on_«ove))) 

(counterdoal  (eval  (deti  'doall  'counterdoal))) 

(feasible  (eval  (deti  'doall  'feasible))) 

(succeeded  (eval  (deti  'doall  'succeeded))) 

(failed  (eval  (deti  'doall  'failed)})) 

(aakefor*  avoid  (doal) 

(succeeded  (eval  (deti  'doal  'succeeded))) 

(failed  (eval  (deli  'dual  'failed)))) 


OTHELLO  PROGRAM 
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(def  othello 
(lexer  (par**) 

(arm  board  t  8  8) 

(seta  xxxx  nil) 

(init) 

(cond  dor  (eo  paraa  0) 

(null  (ard  1))) 

(readslart  7u/14721ja/«<orkindcp*/init)) 

(t 

(readstart  (art  1)))) 

(cond  ((or  (less*  paraa  2) 

(null  (art  2))) 

(load  7u/14721ja/«orkindcex/otheliodoals)) 

(t 

<lotd  (art  2)))) 

(do  ((ac  1  (14  «.•)) 

(tv)) 

((eeual  tc  60)) 

(diselav) 

(tove  (readtove)  'black.) 

(display) 

(princ  'one  toeent'Hterpri) 

(seta  tree  (search  board)) 

(plauboard  tree)))) 


(def  readtove 
(latbda  0 

(prod  (tetp) 
loop 

(princ  'black  --  enter  uour#ove  ') 

(seto  tetp  (read)) 

(cond  (<eo  tetp  7) 

(nevout  tree) 

(do  loop)) 

((eo  tetp  'b) 

(display) 

(do  loop)) 

((ea  leap  't) 

(pp  tree) 

(do  loop)) 

((eo  tetp  's) 

(princ  'naae  of  fila  t  *) 

(tavedate  (ratoa)) 

(do  loop)) 

((and  tetp 

(or  (atoa  leap) 

(not  (eo  (lendth  leap)  2)) 
(not  (validtove  tetp  'black)) 
(null  leap))) 

(princ  'invalid  tov*  —  lr*  adain') 
(tarpri) 

(do  loop))) 

(return  tetp)))) 


(def  aove 

(latbda  (space  color) 
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(cood  ItfiC * 

(apple  'board  (cons  color  space)) 

'we  '(laobda  (k) 

(aid  (flirable  space  (sublist  k  space)  color) 
(flip  space  (sublist  k  space)  color)) ) 
(adjacent  space)))))) 


(def  flip 

(lambda  (space  dir  color) 

(apple  'board  (cons  color  (addlist  space  dir))) 

(cond  ((eoual  (apple  'board  (addlist  (addlist  space  dir)  dir)) 
(op  color)) 

(flip  (addlist  space  dir)  dir  color))))) 


(def  validmove 
(lambda  (space  color) 

(some  '(lambda  (k) 

(flirable  space  (sublist  k  'space)  color)) 
(adjacent  srace)))) 


idef  flieable 
(lambda  (space  dir  color) 

(cond  ((and  (validr  (addlist  space  dir)) 

(eoual  (apple  'board  (addlist  space  dir)) 
(or  color))) 

(flirable2  space  dir  color))))) 


idef  flieable2 
(lambda  (space  dir  color) 

(and  (validr  (addlist  space  dir)) 

(cood  ((eoual  (apple  'board  (addlist  spec*  dir)) 
(op  color)) 

(flirable2  (addlist  space  dir)  dir  color)) 
((eoual  (apple  'board  (addlist  space  dir)) 
color) 

(addlist  space  dir)))))) 

(def  diselae 
(lambda  0 

(do  ((i  0  (It  i») 

((dreaterp  i  7)) 

(do  ((J  0  (It  j))) 

((dreaterp  J  7)) 

(disrlael  i  J; 

(pr*nc  *  ’)) 

(princ  i) 

(terpri) 

(terpri)) 

(do  ((J  0  (It  J))) 

((dreaterp  J  7)> 

(princ  J) 

(princ  •  ’)) 

(terpri))) 


(def  disrlael 
(lambda  (i  J) 
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(cond  ((null  (board  i  J) > 

(princ  • . ’)) 

(t 

(princ  (board  i  j)))))) 

(dcf  init 
(lubda  () 

(set*  (side  'counterfoil) 

(seta  pselist  nil) 

(seta  teardoals  nil) 

(seta  reradoals  nil))) 

(dcf  readstart 
(laabda  (filenaae) 

(seta  pKinfile  filenaae)) 

(do  ((i  0  (If  i») 

((dreaterp  i  7)) 

(do  ((J  0  m  J))) 

((dreaterp  j  7)) 

(board  (read  rl)  i  j))> 
(close  pt))) 

(def  savedaae 
(laabda  (filenaae) 

(seta  pt(outfile  filenaae)) 

(do  ((i  0  (If  i)» 

((dreaterp  i  7)) 

(do  ((J  0  (If  J») 

((dreaterr  j  7)) 

(print  (board  i  J)  rt> 
(terrri  pt))) 

(close  Pt))) 

(def  validp 
(laabda  (subs) 

(and  (lessp  (car  subs)  8) 
(dreaterp  (car  subs)  -l) 
(lessp  (cadr  subs)  8) 
(dreaterp  (cadr  subs)  -1)))) 

(def  op 

(laabda  (color) 

(cond  ((eaual  color  'white) 
'black) 

(t 

’white)))) 


(def  addlist 
(laabda  (11  12) 

(aeecar  'f  11  12))) 

(def  sublist 
(laabda  (11  12) 

(aarcar  11  12))) 


(def  adjacent 
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(laabda  (sou) 

(subset  'valid?  (oaecar  '(laabda  (k) 

(addlist  k  sou)) 

'((1  G)  (1  1)  (0  1)  (-1  1)  (-1  C)  (-1  -1) 
(0-1)  (1 -»))))) 

(def  tvo.auav 
(laabda  (sou) 

(subset  'valid?  (aaecar  '(laabda  (k) 

(addlist  k  sou)) 

'((2  0)  (2  2)  (0  2)  (-2  2)  (-2  0)  (-2  -2) 
(0  -2)  (2  -2)))))) 

(def  ce* 

(nlaobda  (earaos) 

(tarras  (car  earaos)  t  8  8) 

(do  <<i  0  (14  i») 

((Sreater?  i  7)) 

(du  ( ( J  0  (14  j))) 

((Sreater?  J  7)) 

(aeels  (car  earaos) 

(list  (arris  (cadr  earaos)  (list  i  J))  i  J)))))) 


(def  continue_rlas 
(laabda  0 

(seta  xxxx  (not  xxxx)))) 

(def  act 

(laabda  (seace  color) 

(a? els  'erwironaent  (cons  color  seace)) 

(aaec  '(laabda  (k) 

(and  (aflieable  seace  (sublist  k  seace)  colur) 
(afli?  seace  (sublist  k  >racv)  color))) 
(adjacent  seace)))) 


(def  aflie 

(laabda  (seace  dir  color) 

(arris  'environoent  (cons  color  (addlist  seace  dir))) 

(cond  ((eoual  (arris  'environment  (addlist  (addlist  seace  dir)  dir)) 
(or  color)) 

(aflie  (addlist  seace  dir)  dir  color))))) 


(def  aflieable 
(laabda  (seace  dir  color) 

(cond  ((and  (valid?  (addlist  seace  dir)) 

(esuel  (arris  'environoent  (addlist  srace  dir)) 
(or  color))) 

1  (aflietble2  seace  dir  color))))) 


(def  tflieable2 
(laabda  (seace  dir  color) 

(and  (valid?  (addlist  seace  dir)) 

(cond  ((eoual  (aerie  'environoent  (addlist  srace  dir)) 
(or  color)) 

(aflieable2  (addlist  trace  dir)  dir  color)) 
((eoual  (aerie  'environoent  (addlist  seace  dir)) 
color) 
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(addlist  suet  dir)))))) 


(dtf  adisrla* 

(lambda  0 

(do  ((i  0  (U  i))) 
((greater?  i  7)) 

(do  ((J  0  (1+  J») 
((greater?  j  7)) 
(adisplavl  i  j) 
(Mine  ’  *» 

(Mine  i) 

(terpri) 

(terpri)) 

(do  ((J  0  (H  J))) 
((greater?  j  7)) 
(princ  J) 

(print  *  *)) 

(terpri))) 


(def  adisrlavl 
(lambda  (i  J) 

(rood  ((null  (environment  i  j>) 

(princ  ' . ')) 

(t 

(princ  (environment  i  j)))))) 


(def  avalidmove 
(lambda  (space  color) 

(some  '(lambda  (k) 

(aflipable  space  (sublisl  k  w»*ce)  color)) 
(adjacent  space)))) 
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'(  This  file  contains  all  the  variable  definitions 
•and  otheLlo  functions  that  are  explicitly  called 
in  the  othello  *oal  objects  ) 


(seta  eidsas  '(  (2  2)  (2  3)  (2  4)  (2  5) 

(3  2)  a  3)  (3  4)  (3  5) 

(4  2)  (4  3)  (4  4)  (4  3) 

(S  2)  (5  3)  (5  4)  (5  5)  » 

(set*  sideses  '(  (0  2)  (0  3)  (0  4)  (0  S) 

(2  0)  (3  0)  (4  0)  (5  0) 

(7  2)  (7  3)  (7  4)  (7  5) 

(2  7)  (3  7)  (4  7)  (5  7)  )) 

(seta  nearsidesas  '(  (1  2)  (1  3)  (1  4}  (1  5) 

(2  1)  (3  1)  (4  1)  (S  1) 

(4  2)  (4  3)  (4  4)  (4  5) 

<2  4)  (3  4)  (4  4)  <5  4)  )) 

(seta  enrsos  '(  (0  0)  (0  7)  <7  0)  (7  7)  » 

(seta  sidenearenr  '(  <0  1)  (1  0)  (1  7)  (0  4) 

(7  1)  (4  0)  (4  7)  (7  4)  >) 

(seta  notsidenearenr  '(  (1  1)  (1  4)  (4  1)  (4  4)  )) 

(seta  nearenr  (append  sidenearenr  notsidenearenr)) 

(seta  alldirs  '((1  1)  (1  0)  (0  1)  (1  -1)  (-1  1)  (-1  -1)  (-1  0)  (0  -1))) 

'(  returns  list  of  spaces  that  are  two_away  fro*  the  souare  enr 
and  of  the  sate  color  as  side) 

(def  na.two.auay 
(laabda  (enr  side) 

(prod  (1st) 

(•eecer  '(laabda  (k) 

(and  (eoual  (environeent  (car  k>  (cad r  k>) 
side) 

(cons  k  1st))) 

(two. away  enr)) 

(return  1st)))) 

'(  indicates  is  there  is  a  ledal  play  two.awaw  f roe  position  enr  for  the 
color  defined  in  side) 

(def  earLPlay.l_2.away 
(laabda  (enr  side) 

(prod  (fled) 

( oarca r  '(laabda  (k) 

(and  (null  (environaent  (car  k)  (cadr  k))) 
(mlidaove  k  side)  (seto  flad  t))) 
(two.avay  enr)) 

(return  flad)))> 

'(  finds  a  play  in  the  direction  of  dir  that  will  turn  over 
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the  met  in  the  souart  ros) 

(def  tum_rl»s 
(lambda  (ns  dir) 

(prod  (side  fls  kl  k2  net) 

(set#  side  (environment  (car  tos)  (cedr  ns))) 

(sete  net  ns) 

loot  (seta  net  (list  (add  (car  net)  (car  dir)) 

(add  (cadr  net)  (cadr  dir)))) 

(cond  ((or  (>  (abs  (car  net))  7) 

(>  (tbs  (cadr  net)}  7) 

«  (car  net)  0) 

«  (cadr  new)  0))  (return  nil)) 

((ewal  (environment  (car  new)  (cadr  new))  side) 

(do  loot)) 

((null  (environment  (car  new)  (cadr  net))) 

(seta  kl  net)) 

(t  (seta  k2  net))) 

(and  (null  fid)  (seta  fid  t)  (seta  net  tus) 

(seta  dir  (list  (times  *1  (car  dir))  (times  -1  (cadr  dir)))) 
(do  loop)) 

(cond  ((or  (null  kl)  (null  k2))  (return  nil)) 

(t  (return  kl)))))) 

'(  finds  all  ledal  moves  that  till  turnover  the  Piece  in  the  ros  souare) 
(def  tumjwves 
(lambda  (ros) 

(prod  (1st) 

(marcar  '(lambda  (k) 

(and  (seta  k  (turn_rlas  ros  k)) 

(seta  1st  (cons  k  1st)))) 

'((1  1)  (1  -1)  (1  0)  (0  1))) 

(return  1st)))) 

'(  finds  a  plat  in  direction  dir  that  till  allot  the  piece  in  position  pus 
to  be  turned  over  on  the  next  Plat  ) 

(def  set-ur.Umurlat 
(lambda  (ros  dir) 

(prod  (side  fid  kl  k2  k3  net) 

(seta  side  (environment  (car  ros)  (cadr  ros))) 

(seta  net  ros) 

loop  (seta  net  (list  (add  (car  net)  (car  dir)) 

(add  (cadr  net)  (cadr  dir)))) 

(cond  ((or  (>  (tbs  (car  net))  7) 

(>  (tbs  (cadr  net))  7) 

K  (car  net)  0) 

(<  (cadr  net)  0))  (return  nil)) 

((eaual  (environment  (car  net)  (cadr  net))  side) 

(and  (seta  k3  (cons  net  k3))  (do  loop))) 

((null  (environment  (car  new)  (cadr  new))) 

(seta  kl  (cons  new  kl)))) 

(and  (null  fid)  (seta  fid  t)  (seta  net  rvs) 

(seta  dir  (list  (times  -1  (car  dir))  (time*  -1  (cadr  dir)))) 
(do  lour)) 

(return  (append  k3  kl))))) 
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(def  set_ur.tgm_*oves 
(laabda  (pos) 

(pros  (1st) 

(aapcar  '(laabda  (k) 

(and  (seta  1st  (append  1st 

<set-uP.turnjplay#os  15)))) 

'((1  1)  (1  -1)  (1  0)  (0  1)» 

(return  1st)))) 

'(  set_up_aoves  finds  the  set  of  all  souares  that  if  side  could  control  tl*» 
the  doal  souare  could  be  occupied  on  Uie  next  turn) 

(def  set.up _aoves 
(laabda  (cnr  side) 

(pros  (lstl  lst2) 

(or  (seta  lstl  (lum_tardets  vone.avw  cnr)  (op  side)))  (return  nil)) 
loop 

(seta  lst2  (append 

(set.up_tum.plau  (car  lstl) 

(sub.pos  (car  lstl)  cnr)) 

lst2)) 

(and  (seta  lstl  (cdr  lstl))  (So  loop)) 

(return  lst2>)>) 

'(  leSalsa?  tests  if  diven  pos  is  a  lesal  one) 

(def  lesalsa? 

(laabda  (k) 

(and  (<  (car  k)  8) 

(>  (car  k)  -1) 

«  (cadr  k)  8) 

(>  (cadr  k)  -1)))) 

'(  one.awau  returns  all  lesal  souares  one  position  awav  froa 
specified  position) 

(def  one.auau 
(laabda  (kl) 

(pros  (1st) 

(set*  1st 

(sspcsr 

'(laabda  <k2)  (list  (add  (car  kl)  (car  k2)) 

(add  (csdr  kl)  (cadr  k2)») 

'((1  1)  (1  0)  (0  1)  (1  -l)  (-1  1)  (-1  -1)  (-1  0)  (0  -1»» 

(setu  lit  (subset  'lesalsa?  1st)) 

(return  1st)))) 

'(  tum_tsrSets  Siveo  a  list  of  board  positions  returns  those  occupied 
by  the  specified  side) 

(def  turrutardets 
(laabda  (kl  side) 

(prod  (1st) 

(aapcar 
'(laabda  (k2) 

(and  (eeual  (env  k2)  side)  (sete  1st  (cons  k2  1st)))) 
kl) 

(return  1st)))) 


(  env  is  a  sindle  ardueaent  version  of  environaent) 
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(def  env 
(laabda  (k) 

t environment  (car  k)  (cadr  k)))) 

'4  this  is  not  a  sood  utility) 

<def  enr.tesl 
(laabda  (k) 

(and  (null  (env  k))  (avalidaove  k  'black)))) 

'(  add_ros  input  -  two  eeual  size  list  of  nuabers 

output  =  list  of  suai  of  nuabers  in  tlie  it^ul  lists) 

(def  add_POS 
(laabda  (kl  k2) 

(prod  (1st) 
loop 

(seta  1st  (cons  (add  (car  kl)  (car  k2))  1st)) 

(seta  kl  (cdr  kl)) 

(seta  k 2  (cdr  k2)) 

(and  kl  (So  loop)) 

(return  (reverse  1st))))) 

'(sub-pos  input  *  two  eaual  size  list  of  nuabers 

output  *  list  of  subtractions  of  second  nuab  set  frua  first) 

(def  sub-pos 
(laabda  (kl  k2) 

(pros  (1st) 
loop 

(seta  1st  (cots  (diff  (car  kl)  (car  k2))  1st)) 

(seta  kl  (cdr  kl)) 

(seta  k2  (cdr  k2)) 

(and  kl  (So  loop)) 

(return  (reverse  1st))))) 

'(  one.aeae  returns  all  led*}  souares  one  position  awe*  froa 
specified  position) 

(def  one.away 
(laabda  (kl) 

(prod  (1st) 

(seta  1st 
(aaecar 

'(laabda  (k2)  (list  (add  (car  kl)  (car  k2)) 

(add  (cadr  kl)  (cadr  k2)))) 

alldirs)) 

(seta  1st  (subset  'lesalsa?  1st)) 

(return  1st)))) 

^  Piece  _rtm  input  »  position  and  a  direction 

output  *  pattern  of  black  white  and  blank  seuares  in  direction) 

(def  piece-ptm 
(laabda  (pos  dir) 

(prod  (new  lstl  lst2  tap) 

(seta  nee  pos) 
loop 

(seta  nee  (add_pos  nee  dir)) 

(cond 

((lesalsa7  nee)  (seto  1st!  (cons  (list  (env  new)  nrw)  lsil)) 
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(jo  lOOp))} 

1 001*2 
(cond 

((null  1st!)  (return  lst2)> 

((null  lst2)  (seU  1% 12  (cons  (car  lstl)  lst2>)) 

((eoual  (csar  lstl)  (caar  lst2)) 

(seU  t*r  (cons  (cadar  lstl)  (cdar  lst2)>) 

(seta  Up  (cons  (caar  lst2)  Up)) 

(seta  lst2  (cons  Up  (cdr  lst2))>) 

(t  (seU  lst2  (cons  (car  1st!)  Ist2) ) ) ) 

(seU  lstl  (cdr  lstl)) 

(jo  1oop2)))) 

'(  tum_to_save  input  *  position  direction  and  side  to  save  sou  a  re  for 

output  *  location  of  op  side  reice  to  be  turned  over  or  nil) 

(def  tum_to_save 
(laabda  (ros  dir  side) 

(proj  (1st) 

(seta  1st  (pie^e-ptm  pos  dir)) 

(cond  ((and  (eoual  (caar  1st)  side)  (eoual  (caadr  1st)  (ur  side))) 

(return  (cadadr  1st))) 

(t  (return  nil)))))) 

'(  tum_all_to_save  input  -  position  to  prevent  other  side  fru«  rlrainj  in 

ouUut  -  list  of  positions  of  op  side  pieces  to  turn  over) 

(def  tum_all_U-save 
(laabda  (pos  side) 

(delete  nil 

(■apcar 

'(laabda  (k)  (tum.to.save  pos  k  side)) 
alldirs)))) 

'(  delete-list  deletes  elements  of  the  first  list 
fro*  the  second  list) 

(def  delete.list 
(laabda  (lstl  lst2) 

(pros  0 

(aarcar  '(laabda  (k) 

(seU  lst2  (deleU  k  lst2))) 

lstl) 

(return  lst2)))) 
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(seta  pselist  (aarcar 

'(laabda  (k) 

(Soalinst  >1  ay  k)) 

(subset  'cnr.iest  '(<0  £»  (0  7)  (7  0)  (7  7))))) 


(def  loesoalpair 
(laabda  0 

(list  'iaprove_rosition  (Soalinst  'prevent  '(iarrove-rosition))))) 

'(  this  is  a  Seneric  Soal  for  the  conjunction  of  two  specific  soals  ) 

(take fore  and  (Soall  Soal2) 

(subsoal  '(Soall  Soal2)) 

(sututot-on-Mve  '(soall  soal2)) 

(counterSoal  (list  (Soalinst  'or  (list  (car  (Seti  Soall  'cuunterSoal)) 

(car  (Seti  Soal2  ‘counterSoal)/))))) 

'(  this  is  a  Seneric  Soal  for  the  disjunction  of  two  specific  Soals  ) 
(aakefora  or  (soall  Soal2) 

(subsoal  '(Soall  soal2)) 

(sub_not.oruove  '(nil)} 

(counterSoaldist  (Soalinst  'and  (list  (car  (Seti  Soall  'counterSoal)) 

(car  (seti  soal2  'counterSoal )))))) ) 


'(  toe  level  soal  for  olhello  play) 

(aakesoal  iwrcve_position 

(coaiterSoal  (list  (Soalinst  'prevent  '(iaprove-rosition)))) 

(sutSoal  '(stck_a.cnr  ier-a-cnr  plas.side  plav_aiddle  plas.any)) 
(s<jb_not_orv_*ove  '(atck_a.cnr  i«p_a_cnr  play  side  Plav.aiddle  elav-attu))) 

'(  this  is  a  Seneric  soal  that  instantiate*  only  cuuritersoals  ) 

(aakefort  prevent  (Snaae) 

(counterSoal  (list  Snaae)) 

(subsoal  nil)) 

'(  othello  Soal  to  rlav  in  a  comer  ) 

(•akeSoal  atck_a_cnr 
(counterSoal  (list  'dfnd-s.cnr)) 

(s>bSoal  (aaecar  '(laabda  (k) 

(Soalinst  'atck_cnr  k)) 

'(  (0  0)  (0  7)  (7  0)  (7  7)))) 

(sub-not.oruaove  (tapes*  '(laabda  <k> 

(soalinst  'atck.cn r  k)) 

'(  (0  0)  (0  7)  (7  0)  (7  7))))) 

'(  counter  Soal  to  stop  atck_a.cnr  froa  plasinS  in  a  corner  ) 

(aakesoal  dfndLt-cnr 
(counterSoal  (list  'atck_a.cnr)) 

(subsoal  nil) 

(ribjwt.oruaov#  (aaecar  '(laabda  (k) 

(Soalinst  'dfnd.cnr  k) ) 

'((0  0)  (0  7)  (7  0)  (7  7))))) 

'(  positional  soal  to  try  to  better  position  around  a  corner  ) 

(aakesoal  iap.a.cnr 
(counterSoal  (list  'stor.a.cnr)) 
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(subteal  (aaecar  'daabda  (k) 

(tealinst  'ite.cnr  k> > 

'<  (0  0)  (0  7)  (7  0)  (7  7)  »> 

(sub_not.on.aove  (aaecar  'daabda  (k) 

(teal ins t  'i*p_cnr  k)) 

'(  (0  0)  (0  7)  (7  0)  (7  7)  )))) 

'(  counter  teal  to  st&-  iae.a.cnr  froa  tettind  a  better  corner  eositiun  ) 
(aaketeal  stoe_a_cnr 
(counterteal  (list  'iaf.J.cnr)) 

(subteal  nil) 

(sub-not.on.aove  (aaecar  'daabda  (k) 

(tealinst  's tor.cn r  k>) 

'(  (0  0>  (0  7)  (7  0)  (7  7)  »» 

'(  instantiates  atck_a_cnr  ateinst  a  specific  comei  ) 

(aakefora  atck_cnr  (corl  cor2) 

(counterteal  (list  (tealinst  'dfnd.cnr  '(corl  cor2)))) 

(subteal  (cons  (tealinst  'elas  '(corl  cor2)) 

(aaecar  'daabda  (k) 

(tealinst  'elas.safe  k)) 

(set_uf_aoves  (list  corl  cor2)  curside)))) 

(sub_not_on_eove  nil) 

(failed  (eoual  (environaenl  corl  cor2)  (or  curside)))) 

'(  counter  teal  of  atck_a_cnr  ) 

(aakefora  dfrxLcnr  (corl  cor2) 

(counterteal  (list  (tealinst  'alck_cnr  '(corl  cor2)))) 

(subteal  (list  (tealinst  'elas  '(corl  cor2)) 

(tealinst  'sto e_elas  '(corl  cor2)))) 

(sub.not.on.aove  nil) 

(failed  (eoual  (environaent  corl  cor2)  (of  curside)))) 

'<  instantiates  iae.a.cnr  ateinst  a  specific  comer) 

(aakefora  iae.cnr  (corl  cor2) 

(counterteal  (list  (tealinst  'stoe.cnr  '(corl  cor2)>)) 

(subteal  (list  (tealinst  *ctrl_1.2_suas  '(corl  cop2) ) ) ) 

(sub_not_onjeove  (list  (tealinst  'ctrl.l_2.auas  '(corl  cor2)))) 
(feasible  (and  (null  (environaent  corl  cor2)) 
t))) 

'(  counter  teal  of  iar.cnr  ) 

(aakefora  stoe.cnr  (corl  cor2) 

(counterteal  (list  (tealinst  'ctrl_cnr  '(corl  cor2)))) 

(subsoal  (list  (tealinst  'rlss  '(corl  cor2)) 

(soalinst  'stoe-1.2.uua*  '(corl  cor2)))) 

(subjwt.on.aove  (list  (tealinst  'elas  '(corl  cor2)) 

(tealinst  'stoe.l-2.auas  '(corl  cor2))))) 

'(  teal  to  elas  on  a  space  that  is  one  seace  reaoved  froa  a  corner  } 
(aakefora  ctrl.l_2.iuas  (corl  cor2) 

(countersoal  (list  (tealinst  'stof.l-2.suss  '(corl  cur2)))) 

(subteal 

(aaecar  'daabda  (k) 

(cond  ((aeaber  k  sidesos) 

(tealinst  'elay.safe  k)) 
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a 

(foalinst  'ftot_nrcnr.fliv.safe  k)))) 
(tvo.auav  '(corl  cor2>  > ) ) 

(sub_not_on_aove  nil)) 


'(  counter  foal  to  ctrL.1  2jm  ) 

(takeforo  stoe_l_2_ivav  (corl  cor2) 

(counterfoil  (list  (foalinst  'ctrl_l_2_auav  '(corl  cor2)))) 

(subfoil  nil) 

(sub_not_on_aove  (aaecar  '(laabda  (k) 

(cond  ((aether  k  sideses) 

(futlirist  >l*v_sife  k)) 

(t 

(foalinst  'not_nrcnr.eliv.sife  k)))) 
(twc.awav  '(corl  cor2))))> 

'(  foal  to  elav  a  eiece  on  one  of  the  side  seuares  ) 

(•ikefoal  elav.side 
(counterfoil  (list  'stoe.elav.side)) 

(subfoal  (aaecar  '(laabda  (k) 

(foalinst  'elav-safe  k)) 

sidesuv)) 

(sub_not_ori_aove  nil)) 

'(  counter  foal  of  elav.side  to  e revent  elavinf  on  the  side  ) 

(aakefoal  stoe-elav.side 
(counterfoil  (list  'elav_side)) 

(subfoal  nil) 

(sub_not.on.Mve  (aaecar  '(lambda  (k) 

(foalinst  'elav.safe  k)) 
sideses))) 

'(  foal  to  elav  in  the  aiddle  which  is  fenerallv  a  safer  nonaffressive  elav  ) 
(aakefoal  elav_aiddle 
(counterfoil  '(nil)) 

(subfoal  (aaecar  '(laabda  (k) 

(foalinst  'elav  k)) 

•idses))) 

'(  elav-safe  is  a  foal  to  elav  on  a  souarei  and  not  be  turned  over  ) 

(take fort  elav.safe  (sel  se2) 

(counterfoil  (list  (foalinst  'elav.safe  '(sel  se2)))) 

(subfoal  (list  (foalinst  'elav  '(sel  se2)> 

(foalinst  'turn. over  '{sel  se2>))) 

(sub_not_onjow  (list  (foalinst  'turnover  '(sel  se2)))) 

•(feasible  (or  (and  (eoual  (environaent  sel  se2)  (oe  curside)) 

(Umuoves  '(sel  se2))) 

(and  (null  (environaent  sel  se2)) 

(avalidMve  '(sel  se2)  curside)))) 

(failed  (and  (eoual  (environaent  se!  se2)  (oe  curside)) 

(null  (tunuaom  '(sel  se2)))))> 

'(  like  elav.safe  but  excludes  elavs  next  to  a  corner  eosition  ) 

(aakeforo  notjrrcnr-elav.Sife  (sel  se2) 

(counterfoil  (list  (foalinst  'not_nrcnr.elav.saff  '(sel  se2>))) 
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(subsoal  (list  (Soalinst  'rlav  '(srl  sr2)) 

(Soalinst  'notjifCfir.tum.owr  '(srl  sr2)))) 

(sub_not.onjMve  (list  (Soalinst  'noljtrcnr.tum.over  '(srl  si*2)))) 

(feasible  (or  (and  (wual  (envirorrikent  srl  *r2)  (or  curside)) 

(delete.list  nearcnr  (turrueoves  '(w*l  w*2)))) 

(and  (null  (environment  irl  sr2)) 

(avalideow  '(srl  sp2)  curside)))) 

(failed  (and  (eoual  (environeenl  srl  sr2)  (op  curside)) 

(null  (delete.list  nearcnr  (turnjaws  '(spI  s**2))))))) 

'(  *ial  to  prevent  opponent  fro*  rlas  on  a  seuare  on  tiie  next  eove  ) 

(eakefort  s tor  j lav  (corl  cor2) 

(counterSoal  nil) 

(subsoal  (MPcar  '(laebda  (k) 

(Soalinst  'turn-over  k) ) 

(tum.all.to.save  (list  corl  cor2)  curside))) 

(subjtotjm^ove  nil)) 

'(  like  turn,  over*  but  does  not  allow  rlay  next  to  comer  ) 

(aakefora  notjircnr.tum.owr  (spI  sp2) 

(counterSoal  (list  (soalinst  'not.nrcnr.tum.owr  '(srl  se2)))) 

(subsoal  (eapcar  '(laebda  (k) 

(Soalinst  'rlay  k)) 

(delete.list  nearcnr  (tumjeows  '(srl  sp2))))) 

(subjiotjxueow  nil) 

(feasible  (delete_list  nearcnr  (tum.eows  '(spI  sp2))))) 

'(  Soal  to  tumjjwr  a  piece  on  a  seuare  ) 

(eakefort  tum_owr  (srl  sp2) 

(counterSoal  '(nil)) 

(subsoal  (asrcar  '(laebda  (k) 

(Soal ins t  'rlay  k)) 

(tum_eoves  '(spI  sp2)))) 

(feasible  (tumjows  '(srl  sp2)))> 

'(  if  no thins  else  works?  then  rlav  anywhere  ) 

(eakesoal  rlav.anw 
(subSoal  (earcar  '(laebda  (k) 

(soalinst  >lav  k)) 

(append  tidsus 

(delete.list  nearcnr  nearsideses) 

(delete.list  nearcnr  sidesw) 
nearcnr)))) 

'(  soal  to  steels  Play  on  a  seuare  ) 

(eakefort  play  (spI  sp2) 

(cowiterSoal  '(nil)) 

(feasible  (and  (null  (environeent  spI  sp2>> 

(avalidaove  '(srl  sp2)  curside))) 

(action  (act  '(spI  sp2)  curside)) 

(uedateaclion  (tow  '(spI  sp2)  curside))) 


